[julia-users] Re: Status of Plots.jl?

[missperovaz]

Thanks a lot Chris and Josef

I was missing the inline("atom")
I hope GR helps me on plotting faster than PyPlot.

thanks,

On Monday, October 17, 2016 at 6:22:51 AM UTC-7, Josef Heinen wrote:
>
> You should probably test (plain) GR first:
>
> using GR
> inline("atom")
> histogram(randn(1))
>
>
> Did you checkout GR master and download the latest run-time?
>
> Pkg.checkout("GR") 
> ENV["GRDIR"]=""
> Pkg.build("GR")
>
>
> On Sunday, October 16, 2016 at 6:45:07 PM UTC+2, missp...@gmail.com wrote:
>>
>> Hi folks,
>>
>> I don't seem to be able to have the display of a graph in GR. I'm calling 
>> the instructions using Atom. 
>>
>> could someone post a Hello World example?
>>
>> thanks, 
>>
>> On Thursday, March 10, 2016 at 5:11:57 AM UTC-8, Daniel Carrera wrote:
>>>
>>> Hello,
>>>
>>> Does anyone know the status of Plots.jl? It seems to have come a long 
>>> way. At least the documentation makes it look pretty complete:
>>>
>>> http://plots.readthedocs.org/en/latest/
>>>
>>> I'm looking at the backends. Does anyone know what "Gr", "Qwt", and 
>>> "unicodeplots" are? Apparently support for Winston was dropped?
>>>
>>> https://github.com/tbreloff/Plots.jl/issues/152
>>>
>>> I don't use Winston, but I'm curious to know what happened. Was Winston 
>>> hard to support?
>>>
>>> I am currently using PyPlot because I need the maturity of Matplotlib, 
>>> but I am happy to see all the effort that's going into making a native 
>>> plotting library for Julia.
>>>
>>> Cheers,
>>> Daniel.
>>>
>>

Re: [julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?

[colintbowers]

I hadn't thought of using the debugger to step through and see where a 
function call ends up. That is a great idea.

Thanks,

Colin

On Tuesday, 18 October 2016 02:01:43 UTC+11, Patrick Belliveau wrote:
>
> I would add the general comment that in julia 0.5 you can use Gallium to 
> step into a call to a base function and explore what's actually being 
> called. For the .< example, from the julia prompt:
>
> using Gallium
> @enter 0.4 .< 0.5
>
> @enter 0.4 .< 0.5 
> In operators.jl:159 
> 158 .!=(x::Number,y::Number) = x != y 
> 159 .<( x::Real,y::Real) = x < y 
> 160 .<=(x::Real,y::Real) = x <= y 
> 161 const .≤ = .<= 
>  
> About to run: (<)(0.4,0.5)
>
> For your problem, checking the documentation seems like a better place to 
> start than firing up the debugger but it's another good tool to have in the 
> toolbox.
>
> Patrick
>
> On Sunday, October 16, 2016 at 4:02:21 PM UTC-7, Colin Bowers wrote:
>>
>> This was a very helpful answer. Thank you very much for responding.
>>
>> Cheers,
>>
>> Colin
>>
>> On 16 October 2016 at 20:23, Milan Bouchet-Valat  wrote:
>>
>>> Le samedi 15 octobre 2016 à 20:36 -0700, colint...@gmail.com a
>>> écrit :
>>> > Hi all,
>>> >
>>> > Twice now I've thought I had overloaded the appropriate functions for
>>> > a new type, only to observe apparent inconsistencies in the way the
>>> > new type behaves. Of course, there were no inconsistencies. Instead,
>>> > the observed behaviour stemmed from overloading a function that is
>>> > not at the bottom of the function chain. The two examples where I
>>> > stuffed up were:
>>> >
>>> > 1) overloading Base.< instead of overloading Base.isless, and
>>> In this case, the help is quite explicit:
>>> help?> <
>>> search: < <= << <: .< .<= .<<
>>>
>>>   <(x, y)
>>>
>>>   Less-than comparison operator. New numeric types should implement this
>>>   function for two arguments of the new type. Because of the behavior of
>>>   floating-point NaN values, < implements a partial order. Types with a
>>>   canonical partial order should implement <, and types with a canonical 
>>> total
>>>   order should implement isless.
>>>
>>> > 2) overloading Base.string(x) instead of overloading Base.show(io,
>>> > x).
>>> This one is a bit trickier, since the printing code is complex, and not
>>> completely stabilized yet. Though the help still gives some hints:
>>>
>>> help?> string
>>> search: string String stringmime Cstring Cwstring RevString RepString
>>> readstring
>>>
>>>   string(xs...)
>>>
>>>   Create a string from any values using the print function.
>>>
>>> So the more fundamental function to override is print(). The help for
>>> print() says it falls back to show() if there's no print() method for a
>>> given type. So if you don't have a special need for print(), override
>>> show().
>>>
>>> > My question is this: What is the communities best solution/resource
>>> > for knowing which functions are at the bottom of the chain and thus
>>> > are the ones that need to be overloaded for a new type?
>>> In general, look at the help for a function. If there's no answer
>>> (which is a most likely a lack in the documentation which should be
>>> reported), look for it in the manual. The latter can always be useful,
>>> even if the help already gives a reply.
>>>
>>> But documentation is perfectible, so do not hesitate to ask questions
>>> and suggest enhancements (ideally via pull requests when you have found
>>> out how it works).
>>>
>>>
>>> Regards
>>>
>>>
>>> > Cheers and thanks in advance to all repsonders,
>>> >
>>> > Colin
>>>
>>
>>

[julia-users] Re: run command inserting spurious newlines into return values

[Tony Kelman]

Powershell has types for xml, so maybe telling it to expect an xml result (or 
convert the string to xml) would result in different output formatting?

Re: [julia-users] Re: Uniqueness check in PriorityQueue

[Júlio Hoffimann]

Thank you Steven, I fixed the issue by storing other objects in the
PriorityQueue.

-Júlio

2016-10-17 14:27 GMT-07:00 Steven G. Johnson :

> Make a copy before you mutate it.  In general, it is not safe to mutate
> the keys of a dictionary, which is what you are doing.
>

[julia-users] Re: run command inserting spurious newlines into return values

[jason . bates]

So, it turns out it's not the run command, as I originally thought.  After 
more digging, I discovered that powershell formats output differently 
depending on whether it is outputting to a console or to another process, 
and that when it outputs to another process it auto-formats the output.

This still doesn't fix my issue with the auto-formatting breaking WinRPM, 
but at least I now know where to start looking.

[julia-users] Re: Uniqueness check in PriorityQueue

[Steven G. Johnson]

Make a copy before you mutate it.  In general, it is not safe to mutate the 
keys of a dictionary, which is what you are doing.

[julia-users] run command inserting spurious newlines into return values

[jason . bates]

Enter code here...

As one of the multitudes stuck behind a corporate firewall, I'm attempting 
to find a work-around for using the WinRPM package (see this 
issue: https://github.com/JuliaPackaging/WinRPM.jl/issues/40).

In the process, I have uncovered some unusual behavior in the run command - 
it appears to be inserting spurious "\r" tokens into the return string.

Specifically, I am attempting to implement tkelman's suggestion of 
replacing the download function in WinRPM.jl with a call to the command 
readstring(`powershell -Command "(new-object 
net.webclient).DownloadString(\"$source\")"`)


When I run this command directly in powershell, it works fine.  The call:
PS D:> (new-object net.webclient).DownloadString(
"https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml;
)
outputs:

http://linux.duke.edu/metadata/repo; xmlns:rpm=
"http://linux.duke.edu/metadata/rpm;>
 1476324538
 
   
obsrepository://build.opensuse.org/windows:mingw:win32/openSUSE_13.2
 

  
362593bb130a5619226350c66aa68aeca30abe84e95756d8e12ca3e511daa0f1
  
cc48185bdbc5003f12311d447ea013209bc6da642960e4477dba36fdf34bebca

  
  1476324543
  1296372
  20002367


  
4f7e3bc3ef333c833a261b3c6587026fae78affc9acff97eaf1e7bc52b791b83
  
17a5e12a0aa74c9f63f702cef354bc6ebe3b26b5eb7c5f9e7911e90f1e918bb1

  
  1476324543
  149321
  916739


  
1fd9c3d32946a500a759cd90dbaf1b5e93f979d88b7631d7d8a08a8a6ef6aa6b
  
411874cbb061a17b86f0984ca58b4eed8724e1955ff0245787075b8d6091a17a

  
  1476324543
  397298
  3647955



However, that same call in julia:
source = "
https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml;
readstring(`powershell -Command "(new-object 
net.webclient).DownloadString(\"$source\")"`)
outputs:

http://linux.duke.edu/metadata/repo; xmlns:rpm=
"http://linux.duk
e.edu/metadata/rpm">
 1476324538
 
   
obsrepository://build.opensuse.org/windows:mingw:win32/openSUSE_13.2
 

  
362593bb130a5619226350c66aa68aeca30abe84e95756d8e12ca
3e511daa0f1
  
cc48185bdbc5003f12311d447ea013209bc6da642960e447
7dba36fdf34bebca
  
  1476324543
  1296372
  20002367


  
4f7e3bc3ef333c833a261b3c6587026fae78affc9acff97eaf1e7
bc52b791b83
  
17a5e12a0aa74c9f63f702cef354bc6ebe3b26b5eb7c5f9e
7911e90f1e918bb1
  
  1476324543
  149321
  916739


  
1fd9c3d32946a500a759cd90dbaf1b5e93f979d88b7631d7d8a08
a8a6ef6aa6b
  
411874cbb061a17b86f0984ca58b4eed8724e1955ff02457
87075b8d6091a17a
  
  1476324543
  397298
  3647955



Notice that the output has now been spuriously formatted to be fixed with. 
 Looking at the raw output of the run command, it has inserted extra "\r" 
tokens into the return string to force the fixed with behavior.

Is this intentional?  Is there a workaround to prevent this?

Regards,
Jason Bates

[julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

The exported logic requires both the real and the imaginary parts  be given.

ComplexField = AcbField(64)
complexValue = ComplexField(1, 0)





On Monday, October 17, 2016 at 8:08:40 AM UTC-4, digxx wrote:
>
> push...

[julia-users] Re: Please help me to convert a BitArray to a Integer array in Julia

[Scott Jones]

1) You should join us in the Gitter 
chatroom https://github.com/JuliaLang/julia, it actually can be a better 
place to get quick answers to simple questions like this than julia-users.
2) I tested with v0.4.5, and it worked fine for me.  Show us (in the Gitter 
chat room) exactly what you did and what you got back from Julia, and we 
can all help figure it out!

Cheers,
Scott

On Monday, October 17, 2016 at 8:54:12 AM UTC-4, Sujoy Datta wrote:
>
> he 
> Thank you, Tim and Scott. I am using version 0.4.5 and both of these 
> methods are not working.Good to know in the latest version, this can be 
> done.
> Anyway, I just found that while adding, the bits becomes numbers, so, I 
> did this (soo.bad trick,I think):
> x=BitArray(falses(20,8))
> y=x+false
>
> By the way, how can I get the newest version? I downloaded this version 
> through Synaptic.
>
>
>
> On Monday, October 17, 2016 at 3:01:53 PM UTC+5:30, Sujoy Datta wrote:
>>
>>
>>
>> I am a new user of Julia. Please help me to convert a nxm BitArray to an 
>> nxm IntegerArray.
>> What I want is to print 1 for 'true' and 0 for 'false'.
>> Thank you in advance.
>>
>

[julia-users] Re: Dataframe without column and row names ?

[Henri Girard]

I didn't success doing it. 
But I did it with iruby is there a way to adapt it ?

def odd_magic_square(n)
  raise ArgumentError "Need odd positive number" if n.even? || n <= 0
  n.times.map{|i| n.times.map{|j| n*((i+j+1+n/2)%n) + ((i+2*j-5)%n) + 1} }
end
 
[3].each do |n|
  #puts "\nSize #{n}, magic sum #{(n*n+1)/2*n}"
  fmt = "%#{(n*n).to_s.size + 1}d" * n
  #odd_magic_square(n).each{|row| puts fmt % row}
end
IRuby.table(odd_magic_square(3))


Le samedi 15 octobre 2016 04:59:20 UTC+2, Henri Girard a écrit :
>
> Hi,
> Is it possible to have a table with only the result ?
> I don't want row /column names.
>
> using DataFrames
> function iain_magic(n::Int)
> M = zeros(Int, n, n)
> for I = 1:n, J = 1:n
> @inbounds M[I,J] = n*((I+J-1+(n >> 1))%n)+((I+2J-2)%n) + 1
> end
> return M
> end
> mm=iain_magic(3)
> df=DataFrame(mm)
>

[julia-users] Uniqueness check in PriorityQueue

[Júlio Hoffimann]

Hi,

Consider the following snippet:

using LightGraphs
using Base.Collections

pq = PriorityQueue(DiGraph, Int)

G = DiGraph(3)
add_edge!(G, 1,2)

enqueue!(pq, G, 1)

# reverse edge
rem_edge!(G, 1,2)
add_edge!(G, 2,1)

enqueue!(pq, G, 2)

It produces this error:

ERROR: ArgumentError: PriorityQueue keys must be unique
 in 
enqueue!(::Base.Collections.PriorityQueue{LightGraphs.DiGraph,Int64,Base.Order.ForwardOrdering},
 
::LightGraphs.DiGraph, ::Int64) at ./collections.jl:366

The operator == is properly defined in LightGraphs and would have yield 
false, however; the PriorityQueue is handling the two items as if they were 
the same. How can this issue be solved or where should I report it?

-Júlio

[julia-users] Local Atom-Juno with remote Julia ?

['Philippe Roy' via julia-users]

Hello,

I'd like to know if it's possible to use a local installation of Juno/Atom 
with a Julia session on another server on the LAN ?

I can connect to the server through SSH and the files would be on the 
server too. I'm just wondering if the console of the Juno editor can be 
linked to a remote Julia session.

Thanks!

Re: [julia-users] Re: Julia 0.5 Highlights

[Stefan Karpinski]

Yes, that's essentially it – except that since we haven't converged on a
particular design, it's hard to say exactly what interfaces are at this
point. But yes, it's something that provides a first class representation
of some protocol/interface.

On Mon, Oct 17, 2016 at 11:33 AM, Brian Rogoff  wrote:

> On Thursday, October 13, 2016 at 1:00:21 PM UTC-7, Stefan Karpinski wrote:
>>
>> No, Function doesn't have signatures, arity or return type as part of its
>> type. The signature of a function is the union of its method signatures,
>> which is potentially very complicated. Type parameters are not
>> contravariant, so they can't be described without massively complicated
>> Julia's (already complicated) type system. Worse still, adding any form of
>> contravariance would almost certainly make important predicates like
>> subtype and type intersection undecidable. There are still things that
>> could be done to get some of the features that you probably want from
>> function types, but dispatching on the return type is unlikely to ever be
>> allowed. Two things that may happen are:
>>
>
> Got it, thanks! I want method signatures for documentation, debugging, and
> as constraints or hints for the compiler, which are exactly what your two
> things provide.
>
> Are these are what you call 'interfaces' in your JuliaCon 2016 keynote,
> discussed here https://github.com/JuliaLang/julia/issues/6975?
>
>
>> 1. Constraining the type signature of a generic function, raising an
>> error if any method returns something that doesn't match:
>>
>> convert{T} :: (T, Any)-->T
>>
>>
>> or whatever syntax makes sense. This would implicitly mean that any call
>> to convert(T,x) would be translated to convert(T,x)::T so that we know
>> convert always returns the type one would expect for it. This is what I was
>> alluding to above.
>>
>> 2. Intersecting a function signature on an argument with a generic
>> function to extract a "sub-function" that will either behave the way we
>> expect it to or raise an error:
>>
>> function mysort!{T}(lt::(T,T)-->Bool, Vector{T})
>> ...
>>
>> end
>>
>>
>> This would mean that any use like lt(a, b) in the function body would
>> implicitly be wrapped as lt(a::T, b::T)::Bool or something like that. This
>> extra type information could potentially allow the compiler to reason
>> better about the function's behavior even in cases where it otherwise can't
>> figure out that much. Of course, in the case that's already fast, we don't
>> need that information since the type of function calls can already be
>> completely inferred.
>>
>> Note that neither of these allow you to dispatch on the type of lt.
>>
>

[julia-users] Re: Parallel file access

[Zachary Roth]

Thanks for the responses.

Raph, thank you again.  I very much appreciate your "humble offering". 
 I'll take a further look into your gist.

Steven, I'm happy to use the right tool for the job...so long as I have an 
idea of what it is.  Would you care to offer more insights or suggestions 
for the ill-informed (such as myself)?

---Zachary



On Sunday, October 16, 2016 at 7:51:19 AM UTC-4, Steven Sagaert wrote:
>
> that because SQLLite isn't a multi-user DB server but a single user 
> embedded (desktop) db. Use the right tool for the job.
>
> On Saturday, October 15, 2016 at 7:02:58 PM UTC+2, Ralph Smith wrote:
>>
>> How are the processes supposed to interact with the database?  Without 
>> extra synchronization logic, SQLite.jl gives (occasionally)
>> ERROR: LoadError: On worker 2:
>> SQLite.SQLiteException("database is locked")
>> which on the face of it suggests that all workers are using the same 
>> connection, although I opened the DB separately in each process.
>> (I think we should get "busy" instead of "locked", but then still have no 
>> good way to test for this and wait for a wake-up signal.)
>> So we seem to be at least as badly off as the original post, except with 
>> DB calls instead of simple writes.
>>
>> We shouldn't have to stand up a separate multithreaded DB server just for 
>> this. Would you be kind enough to give us an example of simple (i.e. not 
>> client-server) multiprocess DB access in Julia?
>>
>> On Saturday, October 15, 2016 at 9:40:17 AM UTC-4, Steven Sagaert wrote:
>>>
>>> It still surprises me how in the scientific computing field people still 
>>> refuse to learn about databases and then replicate database functionality 
>>> in files in a complicated and probably buggy way. HDF5  is one example, 
>>> there are many others. If you want to to fancy search (i.e. speedup search 
>>> via indices) or do things like parallel writes/concurrency you REALLY 
>>> should use databases. That's what they were invented for decades ago. 
>>> Nowadays there a bigger choice than ever: Relational or non-relational 
>>> (NOSQL), single host or distributed, web interface or not,  disk-based or 
>>> in-memory,... There really is no excuse anymore not to use a database if 
>>> you want to go beyond just reading in a bunch of data in one go in memory.
>>>
>>> On Monday, October 10, 2016 at 5:09:39 PM UTC+2, Zachary Roth wrote:

 Hi, everyone,

 I'm trying to save to a single file from multiple worker processes, but 
 don't know of a nice way to coordinate this.  When I don't coordinate, 
 saving works fine much of the time.  But I sometimes get errors with 
 reading/writing of files, which I'm assuming is happening because multiple 
 processes are trying to use the same file simultaneously.

 I tried to coordinate this with a queue/channel of `Condition`s managed 
 by a task running in process 1, but this isn't working for me.  I've tried 
 to simiplify this to track down the problem.  At least part of the issue 
 seems to be writing to the channel from process 2.  Specifically, when I 
 `put!` something onto a channel (or `push!` onto an array) from process 2, 
 the channel/array is still empty back on process 1.  I feel like I'm 
 missing something simple.  Is there an easier way to go about coordinating 
 multiple processes that are trying to access the same file?  If not, does 
 anyone have any tips?

 Thanks for any help you can offer.

 Cheers,
 ---Zachary

>>>

[julia-users] Re: Please help me to convert a BitArray to a Integer array in Julia

[Scott Jones]

Hmmm, I'd tried it on v0.4.7, and the second one did work, I'm surprised it 
failed in v0.4.5.
To get the latest: http://julialang.org/downloads/

On Monday, October 17, 2016 at 8:54:12 AM UTC-4, Sujoy Datta wrote:
>
> he 
> Thank you, Tim and Scott. I am using version 0.4.5 and both of these 
> methods are not working.Good to know in the latest version, this can be 
> done.
> Anyway, I just found that while adding, the bits becomes numbers, so, I 
> did this (soo.bad trick,I think):
> x=BitArray(falses(20,8))
> y=x+false
>
> By the way, how can I get the newest version? I downloaded this version 
> through Synaptic.
>
>
>
> On Monday, October 17, 2016 at 3:01:53 PM UTC+5:30, Sujoy Datta wrote:
>>
>>
>>
>> I am a new user of Julia. Please help me to convert a nxm BitArray to an 
>> nxm IntegerArray.
>> What I want is to print 1 for 'true' and 0 for 'false'.
>> Thank you in advance.
>>
>

Re: [julia-users] Please help me to convert a BitArray to a Integer array in Julia

[Scott Jones]

Good one, Dan! 2 characters can't be beat!  Wonder how the performance 
compares.

On Monday, October 17, 2016 at 9:04:11 AM UTC-4, Dan wrote:
>
> If saving characters is a thing, then:
> julia> a = rand(Bool,3,2)
> 3×2 Array{Bool,2}:
>  false  false
>   true  false
>  false   true
>
>
> julia> 1a
> 3×2 Array{Int64,2}:
>  0  0
>  1  0
>  0  1
>
>
>
> On Monday, October 17, 2016 at 2:08:44 PM UTC+3, Scott Jones wrote:
>>
>> Tim, do you know if there is any difference in performance between the 
>> two methods?
>>
>> Note, Sujoy, the first method that Tim showed is only available on v0.5 
>> and later (some of the nice stuff added to entice people to move off of 
>> v0.4.x to v0.5.x ;-) )
>>
>> On Monday, October 17, 2016 at 5:48:20 AM UTC-4, Tim Holy wrote:
>>>
>>> julia> a = bitrand(3,5)
>>> 3×5 BitArray{2}:
>>>   true  false  false  true   true 
>>>
>>  false   true   true  true  false
>>>   true   true   true  true   true
>>>
>>> julia> Int.(a)
>>> 3×5 Array{Int64,2}:
>>>  1  0  0  1  1
>>>  0  1  1  1  0
>>>  1  1  1  1  1
>>>
>>> julia> convert(Array{Int}, a)
>>> 3×5 Array{Int64,2}:
>>>  1  0  0  1  1
>>>  0  1  1  1  0
>>>  1  1  1  1  1
>>>
>>>
>>> On Mon, Oct 17, 2016 at 2:55 AM, Sujoy Datta  wrote:
>>>


 I am a new user of Julia. Please help me to convert a nxm BitArray to 
 an nxm IntegerArray.
 What I want is to print 1 for 'true' and 0 for 'false'.
 Thank you in advance.

>>>
>>>

Re: [julia-users] Re: Julia 0.5 Highlights

[Brian Rogoff]

On Thursday, October 13, 2016 at 1:00:21 PM UTC-7, Stefan Karpinski wrote:
>
> No, Function doesn't have signatures, arity or return type as part of its 
> type. The signature of a function is the union of its method signatures, 
> which is potentially very complicated. Type parameters are not 
> contravariant, so they can't be described without massively complicated 
> Julia's (already complicated) type system. Worse still, adding any form of 
> contravariance would almost certainly make important predicates like 
> subtype and type intersection undecidable. There are still things that 
> could be done to get some of the features that you probably want from 
> function types, but dispatching on the return type is unlikely to ever be 
> allowed. Two things that may happen are:
>

Got it, thanks! I want method signatures for documentation, debugging, and 
as constraints or hints for the compiler, which are exactly what your two 
things provide.

Are these are what you call 'interfaces' in your JuliaCon 2016 keynote, 
discussed here https://github.com/JuliaLang/julia/issues/6975? 


> 1. Constraining the type signature of a generic function, raising an error 
> if any method returns something that doesn't match:
>
> convert{T} :: (T, Any)-->T
>
>
> or whatever syntax makes sense. This would implicitly mean that any call 
> to convert(T,x) would be translated to convert(T,x)::T so that we know 
> convert always returns the type one would expect for it. This is what I was 
> alluding to above.
>
> 2. Intersecting a function signature on an argument with a generic 
> function to extract a "sub-function" that will either behave the way we 
> expect it to or raise an error:
>
> function mysort!{T}(lt::(T,T)-->Bool, Vector{T})
> ...
>
> end
>
>
> This would mean that any use like lt(a, b) in the function body would 
> implicitly be wrapped as lt(a::T, b::T)::Bool or something like that. This 
> extra type information could potentially allow the compiler to reason 
> better about the function's behavior even in cases where it otherwise can't 
> figure out that much. Of course, in the case that's already fast, we don't 
> need that information since the type of function calls can already be 
> completely inferred.
>
> Note that neither of these allow you to dispatch on the type of lt.
>

Re: [julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?

[Patrick Belliveau]

I would add the general comment that in julia 0.5 you can use Gallium to 
step into a call to a base function and explore what's actually being 
called. For the .< example, from the julia prompt:

using Gallium
@enter 0.4 .< 0.5

@enter 0.4 .< 0.5 
In operators.jl:159 
158 .!=(x::Number,y::Number) = x != y 
159 .<( x::Real,y::Real) = x < y 
160 .<=(x::Real,y::Real) = x <= y 
161 const .≤ = .<= 
 
About to run: (<)(0.4,0.5)

For your problem, checking the documentation seems like a better place to 
start than firing up the debugger but it's another good tool to have in the 
toolbox.

Patrick

On Sunday, October 16, 2016 at 4:02:21 PM UTC-7, Colin Bowers wrote:
>
> This was a very helpful answer. Thank you very much for responding.
>
> Cheers,
>
> Colin
>
> On 16 October 2016 at 20:23, Milan Bouchet-Valat  > wrote:
>
>> Le samedi 15 octobre 2016 à 20:36 -0700, colint...@gmail.com 
>>  a
>> écrit :
>> > Hi all,
>> >
>> > Twice now I've thought I had overloaded the appropriate functions for
>> > a new type, only to observe apparent inconsistencies in the way the
>> > new type behaves. Of course, there were no inconsistencies. Instead,
>> > the observed behaviour stemmed from overloading a function that is
>> > not at the bottom of the function chain. The two examples where I
>> > stuffed up were:
>> >
>> > 1) overloading Base.< instead of overloading Base.isless, and
>> In this case, the help is quite explicit:
>> help?> <
>> search: < <= << <: .< .<= .<<
>>
>>   <(x, y)
>>
>>   Less-than comparison operator. New numeric types should implement this
>>   function for two arguments of the new type. Because of the behavior of
>>   floating-point NaN values, < implements a partial order. Types with a
>>   canonical partial order should implement <, and types with a canonical 
>> total
>>   order should implement isless.
>>
>> > 2) overloading Base.string(x) instead of overloading Base.show(io,
>> > x).
>> This one is a bit trickier, since the printing code is complex, and not
>> completely stabilized yet. Though the help still gives some hints:
>>
>> help?> string
>> search: string String stringmime Cstring Cwstring RevString RepString
>> readstring
>>
>>   string(xs...)
>>
>>   Create a string from any values using the print function.
>>
>> So the more fundamental function to override is print(). The help for
>> print() says it falls back to show() if there's no print() method for a
>> given type. So if you don't have a special need for print(), override
>> show().
>>
>> > My question is this: What is the communities best solution/resource
>> > for knowing which functions are at the bottom of the chain and thus
>> > are the ones that need to be overloaded for a new type?
>> In general, look at the help for a function. If there's no answer
>> (which is a most likely a lack in the documentation which should be
>> reported), look for it in the manual. The latter can always be useful,
>> even if the help already gives a reply.
>>
>> But documentation is perfectible, so do not hesitate to ask questions
>> and suggest enhancements (ideally via pull requests when you have found
>> out how it works).
>>
>>
>> Regards
>>
>>
>> > Cheers and thanks in advance to all repsonders,
>> >
>> > Colin
>>
>
>

Re: [julia-users] Re: Julia types newbie question

[Angel de Vicente]

Hi Simon,

Simon Danisch  writes:

> I'm guessing that is done to prevent overflow.
> So you need to use your own implementation.
> Here are the promote rules defining this behavior: 
> https://github.com/JuliaLang/julia/blob/master/base/reduce.jl#L32
> So in theory you could also implement your own Int type, that has a
> different promote behavior. Probably not worth it, though ;)

OK, thanks, I will check reduce.jl, I was just finding odd how the
promotion happens for some integer types and not others...

,
| julia> typeof(sum([i for i in Int8(1):Int8(10)]))
| Int32
| 
| julia> typeof(sum([i for i in Int16(1):Int16(10)]))   

   
| Int32
| 
| julia> typeof(sum([i for i in Int32(1):Int32(10)]))   

  
| Int64
| 
| julia> typeof(sum([i for i in Int64(1):Int64(10)]))   

   
| Int64 

  
| 
| julia> typeof(sum([i for i in Int128(1):Int128(10)])) 

   
| Int128
`

-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

[julia-users] Re: Julia types newbie question

[Simon Danisch]

I'm guessing that is done to prevent overflow.
So you need to use your own implementation.
Here are the promote rules defining this behavior: 
https://github.com/JuliaLang/julia/blob/master/base/reduce.jl#L32
So in theory you could also implement your own Int type, that has a 
different promote behavior. Probably not worth it, though ;)


Am Montag, 17. Oktober 2016 15:19:51 UTC+2 schrieb Ángel de Vicente:
>
> Hi, 
>
> probably a very basic question, but I'm just starting to play around 
> with Julia types. 
>
> I was hoping to improve the performance of a little program I wrote, so 
> I decided to try Int32 integers instead of the default Int64, but if I 
> try to use sum, it seems that it is expecting Int64 and the result is 
> Int64, defeating the purpose of working with Int32 and actually making 
> the code much slower than the naive version. 
>
> , 
> | julia> typeof(sum([i for i in Int32(1):Int32(100)])) 
> 
>| 
> | Int64 
> ` 
>
> Do I have to write down my own Int32::sum function? I assume I'm missing 
> something quite obvious? 
>
> Thanks, 
> -- 
> Ángel de Vicente 
> http://www.iac.es/galeria/angelv/   
>

Re: [julia-users] row of a matrix

[Yichao Yu]

On Mon, Oct 17, 2016 at 9:22 AM, Chang Kwon  wrote:

>
> It seems that the way Julia handles A[1,:] changed in v0.5.
>
> *julia> **A = [1 2 3; 4 5 6]*
>
> *2×3 Array{Int64,2}:*
>
> * 1  2  3*
>
> * 4  5  6*
>
>
> *julia> **A[1,:]*
>
> *3-element Array{Int64,1}:*
>
> * 1*
>
> * 2*
>
> * 3*
>
>
> *julia> **size(A[1,:])*
>
> *(3,)*
>
>
> A[1,:] used to be a row-vector in v0.4 same as in MATLAB, but it is now a
> column vector. What is the *best and most reasonable* way to retrieve
> rows of a matrix as a row vector? Just transpose it like A[1,:]' ?
>

A[1:1, :]

[julia-users] Re: Status of Plots.jl?

[Josef Heinen]

You should probably test (plain) GR first:

using GR
inline("atom")
histogram(randn(1))


Did you checkout GR master and download the latest run-time?

Pkg.checkout("GR") 
ENV["GRDIR"]=""
Pkg.build("GR")


On Sunday, October 16, 2016 at 6:45:07 PM UTC+2, missp...@gmail.com wrote:
>
> Hi folks,
>
> I don't seem to be able to have the display of a graph in GR. I'm calling 
> the instructions using Atom. 
>
> could someone post a Hello World example?
>
> thanks, 
>
> On Thursday, March 10, 2016 at 5:11:57 AM UTC-8, Daniel Carrera wrote:
>>
>> Hello,
>>
>> Does anyone know the status of Plots.jl? It seems to have come a long 
>> way. At least the documentation makes it look pretty complete:
>>
>> http://plots.readthedocs.org/en/latest/
>>
>> I'm looking at the backends. Does anyone know what "Gr", "Qwt", and 
>> "unicodeplots" are? Apparently support for Winston was dropped?
>>
>> https://github.com/tbreloff/Plots.jl/issues/152
>>
>> I don't use Winston, but I'm curious to know what happened. Was Winston 
>> hard to support?
>>
>> I am currently using PyPlot because I need the maturity of Matplotlib, 
>> but I am happy to see all the effort that's going into making a native 
>> plotting library for Julia.
>>
>> Cheers,
>> Daniel.
>>
>

[julia-users] row of a matrix

[Chang Kwon]

It seems that the way Julia handles A[1,:] changed in v0.5.

*julia> **A = [1 2 3; 4 5 6]*

*2×3 Array{Int64,2}:*

* 1  2  3*

* 4  5  6*


*julia> **A[1,:]*

*3-element Array{Int64,1}:*

* 1*

* 2*

* 3*


*julia> **size(A[1,:])*

*(3,)*


A[1,:] used to be a row-vector in v0.4 same as in MATLAB, but it is now a 
column vector. What is the *best and most reasonable* way to retrieve rows 
of a matrix as a row vector? Just transpose it like A[1,:]' ? 

[julia-users] Re: Status of Plots.jl?

[Josef Heinen]

You should probably test (plain) GR first:
```

using GR

inline("atom")

histogram(randn(1))
```

Did you ``Pkg.checkout("GR") and download the latest run-time?
```
ENV["GRDIR"]=""
Pkg.build("GR")
```

On Sunday, October 16, 2016 at 6:45:07 PM UTC+2, missp...@gmail.com wrote:
>
> Hi folks,
>
> I don't seem to be able to have the display of a graph in GR. I'm calling 
> the instructions using Atom. 
>
> could someone post a Hello World example?
>
> thanks, 
>
> On Thursday, March 10, 2016 at 5:11:57 AM UTC-8, Daniel Carrera wrote:
>>
>> Hello,
>>
>> Does anyone know the status of Plots.jl? It seems to have come a long 
>> way. At least the documentation makes it look pretty complete:
>>
>> http://plots.readthedocs.org/en/latest/
>>
>> I'm looking at the backends. Does anyone know what "Gr", "Qwt", and 
>> "unicodeplots" are? Apparently support for Winston was dropped?
>>
>> https://github.com/tbreloff/Plots.jl/issues/152
>>
>> I don't use Winston, but I'm curious to know what happened. Was Winston 
>> hard to support?
>>
>> I am currently using PyPlot because I need the maturity of Matplotlib, 
>> but I am happy to see all the effort that's going into making a native 
>> plotting library for Julia.
>>
>> Cheers,
>> Daniel.
>>
>

[julia-users] Julia types newbie question

[angel . vicente . garrido]

Hi,

probably a very basic question, but I'm just starting to play around
with Julia types.

I was hoping to improve the performance of a little program I wrote, so
I decided to try Int32 integers instead of the default Int64, but if I
try to use sum, it seems that it is expecting Int64 and the result is
Int64, defeating the purpose of working with Int32 and actually making
the code much slower than the naive version.

,
| julia> typeof(sum([i for i in Int32(1):Int32(100)]))  

  |
| Int64
`

Do I have to write down my own Int32::sum function? I assume I'm missing
something quite obvious?

Thanks,
-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

Re: [julia-users] Please help me to convert a BitArray to a Integer array in Julia

[Dan]

If saving characters is a thing, then:
julia> a = rand(Bool,3,2)
3×2 Array{Bool,2}:
 false  false
  true  false
 false   true


julia> 1a
3×2 Array{Int64,2}:
 0  0
 1  0
 0  1



On Monday, October 17, 2016 at 2:08:44 PM UTC+3, Scott Jones wrote:
>
> Tim, do you know if there is any difference in performance between the two 
> methods?
>
> Note, Sujoy, the first method that Tim showed is only available on v0.5 
> and later (some of the nice stuff added to entice people to move off of 
> v0.4.x to v0.5.x ;-) )
>
> On Monday, October 17, 2016 at 5:48:20 AM UTC-4, Tim Holy wrote:
>>
>> julia> a = bitrand(3,5)
>> 3×5 BitArray{2}:
>>   true  false  false  true   true 
>>
>  false   true   true  true  false
>>   true   true   true  true   true
>>
>> julia> Int.(a)
>> 3×5 Array{Int64,2}:
>>  1  0  0  1  1
>>  0  1  1  1  0
>>  1  1  1  1  1
>>
>> julia> convert(Array{Int}, a)
>> 3×5 Array{Int64,2}:
>>  1  0  0  1  1
>>  0  1  1  1  0
>>  1  1  1  1  1
>>
>>
>> On Mon, Oct 17, 2016 at 2:55 AM, Sujoy Datta  wrote:
>>
>>>
>>>
>>> I am a new user of Julia. Please help me to convert a nxm BitArray to an 
>>> nxm IntegerArray.
>>> What I want is to print 1 for 'true' and 0 for 'false'.
>>> Thank you in advance.
>>>
>>
>>

[julia-users] Re: Please help me to convert a BitArray to a Integer array in Julia

[Sujoy Datta]

he 
Thank you, Tim and Scott. I am using version 0.4.5 and both of these 
methods are not working.Good to know in the latest version, this can be 
done.
Anyway, I just found that while adding, the bits becomes numbers, so, I did 
this (soo.bad trick,I think):
x=BitArray(falses(20,8))
y=x+false

By the way, how can I get the newest version? I downloaded this version 
through Synaptic.



On Monday, October 17, 2016 at 3:01:53 PM UTC+5:30, Sujoy Datta wrote:
>
>
>
> I am a new user of Julia. Please help me to convert a nxm BitArray to an 
> nxm IntegerArray.
> What I want is to print 1 for 'true' and 0 for 'false'.
> Thank you in advance.
>

[julia-users] Re: Nemo AcbField error

[digxx]

push...

[julia-users] Re: Root finding package

[digxx]

well this is only for polynomials, right?

Re: [julia-users] GC rooting for embedding: what is safe and unsafe?

[Gunnar Farnebäck]

Thanks. That makes things clearer.

Den fredag 14 oktober 2016 kl. 14:16:54 UTC+2 skrev Yichao Yu:
>
>
>
> On Fri, Oct 14, 2016 at 7:03 AM, Bart Janssens  > wrote:
>
>> Hi,
>>
>> Replies below, to the best of my understanding of the Julia C interface:
>>
>> On Fri, Oct 14, 2016 at 11:47 AM Gunnar Farnebäck > > wrote:
>>
>>> Reading through the threads and issues on gc rooting for embedded code, 
>>> as well as the code comments above the JL_GC_PUSH* macros in julia.h, I'm 
>>> still uncertain about how defensive it's necessary to be and best 
>>> practices. I'll structure this into a couple of cases with questions.
>>>
>>> 1. One of the use cases in examples/embedding.c is written:
>>>
>>> jl_function_t *func = jl_get_function(jl_base_module, "sqrt");
>>> jl_value_t* argument = jl_box_float64(2.0);
>>> jl_value_t* ret = jl_call1(func, argument);
>>>
>>> if (jl_is_float64(ret)) {
>>> double retDouble = jl_unbox_float64(ret);
>>> printf("sqrt(2.0) in C: %e\n", retDouble);
>>> }
>>>
>>>  
>>>
>> Is this missing gc rooting for argument during the call to jl_call1 or is 
>>> it safe without it?
>>> Would ret need gc rooting to be safe during the calls to jl_is_float64 
>>> and/or jl_unbox_float64?
>>>
>>
>> The jl_call argument must be rooted since func may allocate. I don't 
>> think the operations on ret allocate, but if you're unsure it's better to 
>> root it. Also, as your code evolves you may decide to perform extra 
>> operations on ret and then it's easy to forget the GC rooting at that 
>> point, so I'd root ret here.
>>
>
> jl_call1 (and other jl_call* functions) are special in the sense that it 
> roots it's argument so you don't have to root `argument`
> The ret doesn't have to be rooted if these are all what you are doing with 
> it.
> The only one that should in principle be rooted is actually `func`. 
> However, since it is known to be a global constant you won't get into any 
> trouble without. (If it's a non-const global then you have to)
>  
>
>>  
>>
>>>
>>> 2. 
>>> jl_value_t *a = jl_box_float64(1.0);
>>> jl_value_t *b = jl_box_float64(2.0);
>>> JL_GC_PUSH2(, );
>>>
>>> Is this unsafe since a is not yet rooted during the second call to 
>>> jl_box_float64 and must instead be written like below?
>>>
>>> jl_value_t *a = 0;
>>> jl_value_t *b = 0;
>>> JL_GC_PUSH2(, );
>>> a = jl_box_float64(1.0);
>>> b = jl_box_float64(2.0);
>>>
>>> For a single variable it's just fine to do like this though?
>>> jl_value_t *a = jl_box_float64(1.0);
>>> JL_GC_PUSH1();
>>>
>>>
>> Yes, since jl_box will allocate.
>>
>
> This is correct.
>  
>
>>  
>>
>>> 3. Are
>>> jl_function_t *func = jl_get_function(jl_base_module, "println");
>>> jl_value_t *a = 0;
>>> jl_value_t *b = 0;
>>> JL_GC_PUSH2(, );
>>> a = jl_box_float64(1.0);
>>> b = jl_box_float64(2.0);
>>> jl_call2(func, a, b);
>>> JL_GC_POP();
>>>
>>> and
>>>
>>> jl_function_t *func = jl_get_function(jl_base_module, "println");
>>> jl_value_t **args;
>>> JL_GC_PUSHARGS(args, 2);
>>> args[0] = jl_box_float64(1.0);
>>> args[1] = jl_box_float64(2.0);
>>> jl_call(func, args, 2);
>>> JL_GC_POP();
>>>
>>> equivalent and both safe? Are there any reasons to choose one over the 
>>> other, apart from personal preferences?
>>>
>>
>> They are equivalent, looking at the code for the macro it seems that the 
>> JL_GC_PUSHARGS variant heap-allocates the array of pointers to root, so 
>> that might be slightly slower. I'd only use the JL_GC_PUSHARGS version if 
>> the number of arguments comes from a variable or a parameter or similar.
>>
>
> No JL_GC_PUSHARGS does **NOT** heap allocate the array.
> The difference between the two is pretty small and the performance should 
> be almost not noticeable unless you are doing a lot of things with the 
> boxed variables.
>  
>
>>  
>>
>>>
>>> 4. Can any kind of exception checking be done safely without rooting the 
>>> return value?
>>> jl_value_t *ret = jl_call1(...);
>>> if (jl_exception_occured())
>>> printf("%s \n", jl_typeof_str(jl_exception_occured()));
>>> else
>>> d = jl_unbox_float64(ret);
>>>
>>>
> This is currently safe. It's a little close to the edge of what I think we 
> can always guarantee in the future
>  
>
>> 5. What kind of costs, other than increased code size, can be expected 
>>> from overzealous gc rooting?
>>>
>>
>>
> It leaks local variable addresses to global so the compiler cannot reason 
> about their values as well. This is the "difference" I've mentioned above 
> that you won't notice "unless you are doing a lot of things with the boxed 
> variables"
>  
>
>> These I leave for the experts :)
>>  
>>
>>>
>>> 6. Is it always safe not to gc root the function pointer returned from 
>>> jl_get_function?
>>>
>>>
>> A function should be bound to the symbol you use to look it up, so it is 
>> already rooted.
>>
>
> No. It is only safe to not root the value if it is a const global (well, 
> or you know that it never changes) and is not an 

Re: [julia-users] Please help me to convert a BitArray to a Integer array in Julia

[Scott Jones]

Tim, do you know if there is any difference in performance between the two 
methods?

Note, Sujoy, the first method that Tim showed is only available on v0.5 and 
later (some of the nice stuff added to entice people to move off of v0.4.x 
to v0.5.x ;-) )

On Monday, October 17, 2016 at 5:48:20 AM UTC-4, Tim Holy wrote:
>
> julia> a = bitrand(3,5)
> 3×5 BitArray{2}:
>   true  false  false  true   true 
>
 false   true   true  true  false
>   true   true   true  true   true
>
> julia> Int.(a)
> 3×5 Array{Int64,2}:
>  1  0  0  1  1
>  0  1  1  1  0
>  1  1  1  1  1
>
> julia> convert(Array{Int}, a)
> 3×5 Array{Int64,2}:
>  1  0  0  1  1
>  0  1  1  1  0
>  1  1  1  1  1
>
>
> On Mon, Oct 17, 2016 at 2:55 AM, Sujoy Datta  > wrote:
>
>>
>>
>> I am a new user of Julia. Please help me to convert a nxm BitArray to an 
>> nxm IntegerArray.
>> What I want is to print 1 for 'true' and 0 for 'false'.
>> Thank you in advance.
>>
>
>

[julia-users] Re: What is really "big data" for Julia (or otherwise), 1D or multi-dimensional?

[Scott Jones]

On Friday, October 14, 2016 at 1:00:35 PM UTC-4, Páll Haraldsson wrote:
>
> On Thursday, October 13, 2016 at 7:49:51 PM UTC, cdm wrote:
>>
>> from CloudArray.jl:
>>
>> "If you are dealing with big data, i.e., your RAM memory is not enough 
>> to store your data, you can create a CloudArray from a file."
>>
>>
>> https://github.com/gsd-ufal/CloudArray.jl#creating-a-cloudarray-from-a-file
>>
>
> Good to know, and seems cool.. (like CatViews.jl) indexes could need to be 
> bigger than 32-bit this way.. even for 2D.
>
> But has anyone worked with more than 70 terabyte arrays, that would 
> otherwise have been a limitation?
>

In my previous life, yes, all the time, they were n dimensional sorted 
associative array structures, stored on disk, cached in shared memory for 
all processes to be able to access simultaneously (but that was in 
CachéObjectScript, not Julia).

This is something we (Dynactionize.com, the Belgian startup that I'm at) 
are working on being able to easily do in Julia, using Aerospike and CEPH 
to actually handle having the data stored in a distributed fashion on SSDs 
and disk, but it may be a while before we reach the sorts of scale in Julia 
that I'd been accustomed to with data in Caché (handling healthcare data, 
bank and insurance company data, sensor data, all sorts of different 
applications, even the ESA satellite data).

Anyone know biggest (or just big over 2 GB) one-dimensional array people 
> are working with?
>

Re: [julia-users] Please help me to convert a BitArray to a Integer array in Julia

[Tim Holy]

julia> a = bitrand(3,5)
3×5 BitArray{2}:
  true  false  false  true   true
 false   true   true  true  false
  true   true   true  true   true

julia> Int.(a)
3×5 Array{Int64,2}:
 1  0  0  1  1
 0  1  1  1  0
 1  1  1  1  1

julia> convert(Array{Int}, a)
3×5 Array{Int64,2}:
 1  0  0  1  1
 0  1  1  1  0
 1  1  1  1  1


On Mon, Oct 17, 2016 at 2:55 AM, Sujoy Datta  wrote:

>
>
> I am a new user of Julia. Please help me to convert a nxm BitArray to an
> nxm IntegerArray.
> What I want is to print 1 for 'true' and 0 for 'false'.
> Thank you in advance.
>

[julia-users] Please help me to convert a BitArray to a Integer array in Julia

[Sujoy Datta]

I am a new user of Julia. Please help me to convert a nxm BitArray to an 
nxm IntegerArray.
What I want is to print 1 for 'true' and 0 for 'false'.
Thank you in advance.

Re: [julia-users] Dataframe without column and row names ?

[Milan Bouchet-Valat]

Le lundi 17 octobre 2016 à 06:32 +0200, henri.gir...@gmail.com a
écrit :
> In fact I don't know how to make the nice border but I noticed
> dataframe 
> does it ...
> 
> I only need the nice border for the matrix, but I don't know how to
> do it ?
> 
> Maybe I should ask how to make a nice border in a matrix ?
DataFrames' main feature isn't to provide nice borders... You can try
overriding the show() method for Matrix if you want borders.


Regards

> Regards
> 
> Henri
> 
> 
> Le 15/10/2016 à 22:32, Milan Bouchet-Valat a écrit :
> > 
> > Le vendredi 14 octobre 2016 à 19:59 -0700, Henri Girard a écrit :
> > > 
> > > Hi,
> > > Is it possible to have a table with only the result ?
> > > I don't want row /column names.
> > So why do you create a data frame? Isn't a Matrix enough?
> > 
> > 
> > Regards
> > 
> > > 
> > > using DataFrames
> > > function iain_magic(n::Int)
> > >  M = zeros(Int, n, n)
> > >  for I = 1:n, J = 1:n
> > >  @inbounds M[I,J] = n*((I+J-1+(n >> 1))%n)+((I+2J-2)%n) +
> > > 1
> > >  end
> > >  return M
> > > end
> > > mm=iain_magic(3)
> > > df=DataFrame(mm)