[julia-users] Re: pager in the repl

[Andrea Pagnani]

+1 for a pager in REPL!!!

I was thinking to write something like this post just today

Andrea

On Thursday, May 22, 2014 8:04:05 PM UTC+2, Bob Nnamtrop wrote:
>
> I often find myself wishing for a pager in the repl when outputing large 
> amount of output. I see that there is a Base.less but it is only used on 
> files and not for outputting other stuff in the repl. In fact, it would be 
> great to have support for less, head, and tail like functionality for 
> looking at arrays, hashes, etc. Thus to be able to do:
>
> arr |> less
> or 
> less(arr)
> or
> arr |> tail
>
> In addition, I think having the output of show() automatically go through 
> less if it longer that one page would be great. I hate seeing 100's of 
> pages of output fly by when, e.g., a huge hash gets "shown" at the prompt 
> (I just cannot seem to get in the habit of typing the ; at the right time). 
> This behavior could be configurable of course.
>
> Bob
>

Re: [julia-users] pager in the repl

[Andrea Pagnani]

The idea to have a pager that allows for browsing efficiently large data 
structures as proposed by Stefan is great but probably too far fetched. 
Also I agree that having a long output paged by default is not what I 
really need in my everyday data/program debugging. Suppose that 
``myprog()`` prints a long output on the screen, what I would really fancy 
 would be something like ``myprog()  |> less``  ( the symbol ``|>``  might 
not be the good one though) or  ``tail``, ``head`` which, I do not know for 
windows system, but at least for MAC and Linux are already available. I use 
it quite often the syntax
command|>less
and redirects you through ``less`` to the line of julia code  where 
``command`` is defined. Is there any way to redirect on the fly STDOUT from 
screen to, say less, but on the fly?

Andrea




On Friday, May 23, 2014 11:45:18 AM UTC+2, Tomas Lycken wrote:
>
> Personally, I love the way Julia outputs large matrices - some rows from 
> the start, followed by "..." and then some rows from the end. If the matrix 
> is both wide and tall, it's truncated in both directions, but the central 
> point is that it's truncated in the middle, rather than on either end. That 
> lets me quickly inspect the entire thing - if it both starts and ends as I 
> expect, it's probably OK even in the parts that I don't see. If i'm not 
> sure, I can always use some more (or less) fine-tuned command (e.g. @show) 
> to look at the entire thing.
>
> The ideal solution to me, would be to do the same thing for all kinds of 
> output: the default way of displaying it would be to truncate it in the 
> middle, and if the user wants something else, they can manually request it. 
> And then, of course, it would be awesome if they could also manually pipe 
> it to something that works just like less, tail or whatever from the native 
> terminal.
>
> But I think making long output in the REPL paginated by default is a bad 
> idea - if I type something that results in a large amount of output just 
> because I forgot to add ; at the end, suddenly I have to get out of the 
> paginated output view before I can type my next command. I don't feel like 
> making the "read-eval-print-loop" more like a 
> "read-eval-print-getoutofpaginatedview-loop"...
>
> // T
>
> On Friday, May 23, 2014 10:06:11 AM UTC+2, Tamas Papp wrote:
>>
>> I don't think a pager is the right solution, for the following reasons: 
>>
>> 1. typing directly in to the REPL running in a terminal is not an 
>> efficient way to program anything nontrivial, most users would use an 
>> IDE (incl Emacs) that would allow scrolling and inspection of a value, 
>>
>> 2. how many elements to print from large arrays etc could be controlled 
>> by something like Common Lisp's *PRINT-LENGTH*, eg see 
>> http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in 
>> Julia, could not find it). 
>>
>> Best, 
>>
>> Tamas 
>>
>> On Thu, May 22 2014, Stefan Karpinski  wrote: 
>>
>> > Now that we have native terminal support, it would be a reasonable 
>> project 
>> > to write a pager in Julia. Why write our own pager (you ask)? Because 
>> it 
>> > could allow you to do things like efficiently page around a huge array 
>> > without having to print the whole thing. You could, e.g., instantly 
>> page to 
>> > the bottom right of a massive, distributed array, without any lag at 
>> all. 
>> > Of course, the thing is you want to use shared infrastructure for doing 
>> > this kind of data exploration in the terminal, IJulia, and maybe your 
>> > editor. But the pager part could be pretty decoupled from that. 
>> > 
>> > 
>> > On Thu, May 22, 2014 at 3:30 PM, Kevin Squire wrote: 
>>
>> > 
>> >> Thanks! 
>> >> 
>> >> 
>> >> On Thursday, May 22, 2014 11:52:12 AM UTC-7, Bob Nnamtrop wrote: 
>> >> 
>> >>> OK done. See https://github.com/JuliaLang/julia/issues/6921 
>> >>> 
>> >>> 
>> >>> On Thu, May 22, 2014 at 12:20 PM, Kevin Squire 
>> >>> wrote: 
>>
>> >>> 
>>  I agree that that would be nice.  Would you be willing to open up an 
>>  issue for this? 
>>  
>>  
>>  On Thu, May 22, 2014 at 11:04 AM, Bob Nnamtrop 
>>  wrote: 
>>
>>  
>> > I often find myself wishing for a pager in the repl when outputing 
>> > large amount of output. I see that there is a Base.less but it is 
>> only used 
>> > on files and not for outputting other stuff in the repl. In fact, 
>> it would 
>> > be great to have support for less, head, and tail like 
>> functionality for 
>> > looking at arrays, hashes, etc. Thus to be able to do: 
>> > 
>> > arr |> less 
>> > or 
>> > less(arr) 
>> > or 
>> > arr |> tail 
>> > 
>> > In addition, I think having the output of show() automatically go 
>> > through less if it longer that one page would be great. I hate 
>> seeing 100's 
>> > of pages of output fly by when, e.g., a huge hash gets "shown" at 
>> the 
>> > prompt (I just cannot seem to get in the habit of typing

Re: [julia-users] pager in the repl

[Andrea Pagnani]

Too far fetched for my programming skills.  As I said, I would be already 
happy with a simple workaround to redirect STDOUT on less.

On Friday, May 23, 2014 2:45:56 PM UTC+2, Mike Innes wrote:
>
> Why do you say it's too far fetched? I agree that it shouldn't be the 
> default, but I don't see any technical issues with the idea.
>
>
> On 23 May 2014 13:36, Andrea Pagnani  >wrote:
>
>> The idea to have a pager that allows for browsing efficiently large data 
>> structures as proposed by Stefan is great but probably too far fetched. 
>> Also I agree that having a long output paged by default is not what I 
>> really need in my everyday data/program debugging. Suppose that 
>> ``myprog()`` prints a long output on the screen, what I would really fancy 
>>  would be something like ``myprog()  |> less``  ( the symbol ``|>``  might 
>> not be the good one though) or  ``tail``, ``head`` which, I do not know for 
>> windows system, but at least for MAC and Linux are already available. I use 
>> it quite often the syntax
>> command|>less
>> and redirects you through ``less`` to the line of julia code  where 
>> ``command`` is defined. Is there any way to redirect on the fly STDOUT from 
>> screen to, say less, but on the fly?
>>
>> Andrea
>>
>>
>>
>>
>> On Friday, May 23, 2014 11:45:18 AM UTC+2, Tomas Lycken wrote:
>>>
>>> Personally, I love the way Julia outputs large matrices - some rows from 
>>> the start, followed by "..." and then some rows from the end. If the matrix 
>>> is both wide and tall, it's truncated in both directions, but the central 
>>> point is that it's truncated in the middle, rather than on either end. That 
>>> lets me quickly inspect the entire thing - if it both starts and ends as I 
>>> expect, it's probably OK even in the parts that I don't see. If i'm not 
>>> sure, I can always use some more (or less) fine-tuned command (e.g. @show) 
>>> to look at the entire thing.
>>>
>>> The ideal solution to me, would be to do the same thing for all kinds of 
>>> output: the default way of displaying it would be to truncate it in the 
>>> middle, and if the user wants something else, they can manually request it. 
>>> And then, of course, it would be awesome if they could also manually pipe 
>>> it to something that works just like less, tail or whatever from the native 
>>> terminal.
>>>
>>> But I think making long output in the REPL paginated by default is a bad 
>>> idea - if I type something that results in a large amount of output just 
>>> because I forgot to add ; at the end, suddenly I have to get out of the 
>>> paginated output view before I can type my next command. I don't feel like 
>>> making the "read-eval-print-loop" more like a "read-eval-print-
>>> getoutofpaginatedview-loop"...
>>>
>>> // T
>>>
>>> On Friday, May 23, 2014 10:06:11 AM UTC+2, Tamas Papp wrote:
>>>>
>>>> I don't think a pager is the right solution, for the following reasons: 
>>>>
>>>> 1. typing directly in to the REPL running in a terminal is not an 
>>>> efficient way to program anything nontrivial, most users would use an 
>>>> IDE (incl Emacs) that would allow scrolling and inspection of a value, 
>>>>
>>>> 2. how many elements to print from large arrays etc could be controlled 
>>>> by something like Common Lisp's *PRINT-LENGTH*, eg see 
>>>> http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in 
>>>> Julia, could not find it). 
>>>>
>>>> Best, 
>>>>
>>>> Tamas 
>>>>
>>>> On Thu, May 22 2014, Stefan Karpinski  wrote: 
>>>>
>>>> > Now that we have native terminal support, it would be a reasonable 
>>>> project 
>>>> > to write a pager in Julia. Why write our own pager (you ask)? Because 
>>>> it 
>>>> > could allow you to do things like efficiently page around a huge 
>>>> array 
>>>> > without having to print the whole thing. You could, e.g., instantly 
>>>> page to 
>>>> > the bottom right of a massive, distributed array, without any lag at 
>>>> all. 
>>>> > Of course, the thing is you want to use shared infrastructure for 
>>>> doing 
>>>> > this kind of data exploration in the terminal, IJulia, and maybe your 
>>

Re: [julia-users] pager in the repl

[Andrea Pagnani]

And what about paging the STDOUT produced by program from the repl?

I often would like to do something like

julia> myprog() |> less

and piping the STDOUT of myprog() on the pager. Would it be possible?

Andrea  

On Friday, May 23, 2014 6:04:58 PM UTC+2, Stefan Karpinski wrote:
>
> Yes, that might be a good way to do it. Basically the display methods of 
> the Scrollable object (the thing returned by less) could do whatever it 
> needed to do, including show the object in a pager or start a Task that 
> answers questions from a widget about the object to be displayed and return.
>
>
> On Fri, May 23, 2014 at 11:45 AM, Mike Innes 
> > wrote:
>
>> Cool, I'll add this to my ever-growing list :)
>>
>> Perhaps less could emit some kind of Scrollable wrapper type, which would 
>> display itself in the REPL as a pager, or in IJulia as an HTML scroll pane? 
>> I've been meaning to try out  display of arrays anyway, so this 
>> would tie in neatly with that.
>>  
>
>

Re: [julia-users] pager in the repl

[Andrea Pagnani]

Wow this is most amazing 

I'm struggling to understand writesto. I wonder if it would be possible to 
intercept the STDOUT of a function, e.g
function f(N::Int)
   for i=1:N
println(i)
   end
end


julia> f(100) |> less 

But probably it is impossible ... I am already happy!

Thanks Steven

Andrea


On Friday, May 23, 2014 10:28:33 PM UTC+2, Steven G. Johnson wrote:
>
> On Friday, May 23, 2014 4:15:26 PM UTC-4, Steven G. Johnson wrote:
>  
>
>> finally
>> kill(P)
>> end
>>
>>
>>
> (This should be catch, not finally, and should rethrow().) 
>

[julia-users] Re: How use two contition to filtred array?

[Andrea Pagnani]

I think 

klient[   500 .< klient[:,2] .<= 10,:]

should work

Andrea

On Tuesday, June 10, 2014 8:41:17 PM UTC+2, paul analyst wrote:
>
> How use two conditions to filtred array?
>
> Left and right side this code separatly are good. But how use booth 
> conditions in filter ? (take rows with <1 and >500 in col 2)
>
> klient[klient[:,2].<=10;:] & klient[klient[:,2].>500;:]
>
> Paul
>

[julia-users] slow trigonometric functions with respect to libc counterpart

[Andrea Pagnani]

Dear all,

julia's trigonometric functions seem to be almost 5 time slower than their 
libc counterpart (at least on my MacBook Pro OS X 10.9.2):

function test1()

const N=1000;
@time begin
s = 0.0
for i=1:N
s+= ccall((:sin,"libc"),Float64,(Float64,),i) 
end
println(s)
end
@time begin
s = 0.0
for i=1:N
s += sin(i)
end
println(s)
end
end


If you run this simple code you obtain

julia> test1()
1.9558914085412562
elapsed time: 0.275374895 seconds (88 bytes allocated)
1.9558914085412367
elapsed time: 1.567108143 seconds (88 bytes allocated)
1.9558914085412367

The same behaviour is obtained with other trigonometric functions
Is this something to be expected?

Re: [julia-users] Re: slow trigonometric functions with respect to libc counterpart

[Andrea Pagnani]

Hi Ivar, 

I tried your version on my system (which I called test2.jl) and
julia> test2()
1.9558914085412562
elapsed time: 0.31957987 seconds (23456 bytes allocated)
1.9558914085412367
elapsed time: 1.488734269 seconds (136 bytes allocated)
1.9558914085412367
elapsed time: 1.549758093 seconds (136 bytes allocated)

Some misconfiguration on my system?

Also it does not seems to be something related to BigInt as

function test3()

const N=1000;
@time begin
s = 0.0
for i=1.0:1.0:float64(N)
s+= ccall((:sin,"libc"),Float64,(Float64,),i) 
end
println(s)
end
@time begin
s = 0.0
for i=1.0:1.0:float64(N)
s += sin(i)
end
println(s)
end
end

Now everything is Float64, yet

julia> test3()
1.9558914085412562
elapsed time: 0.321183789 seconds (320 bytes allocated)
1.9558914085412367
elapsed time: 1.521137678 seconds (320 bytes allocated)




On Saturday, March 1, 2014 8:19:05 PM UTC+1, Ivar Nesje wrote:
>
> Andreas: You compare libopenlibm to the system libm
>
> function test1()
>const N=1000;
>@time begin
>s = 0.0
>for i=1:float(N)
>s+= ccall((:sin,"libc"),Float64,(Float64,),i)
>end
>println(s)
>end
>@time begin
>s = 0.0
>for i=1:float(N)
>s+= 
> Base.nan_dom_err(ccall((:sin,"libopenlibm"),Float64,(Float64,),i),i)
>end
>println(s)
>end
>@time begin
>s::Float64 = 0.0
>for i=1:float(N)
>s += sin(i)
>end
>println(s)
>end
>end
> test1 (generic function with 1 method)
>
> does not give a significant difference between the built in `sin` function 
> and ccall.
>
> Ivar
>
>
> kl. 19:57:03 UTC+1 lørdag 1. mars 2014 skrev Andreas Noack Jensen følgende:
>>
>> But it is weird that if the definition from math.jl is added such that
>>
>> function test1()
>> const N=1000;
>> @time begin
>> s = 0.0
>> for i=1:float(N)
>> s+= ccall((:sin,"libc"),Float64,(Float64,),i)
>> end
>> println(s)
>> end
>> @time begin
>> s = 0.0
>> for i=1:float(N)
>> s+= nan_dom_err(ccall((:sin,"libm"),Float64,(Float64,),i),i)
>> end
>> println(s)
>> end
>> @time begin
>> s::Float64 = 0.0
>> for i=1:float(N)
>> s += sin(i)
>> end
>> println(s)
>> end
>> end
>>
>> I get
>>
>> julia> Newton.test1()
>>
>> 1.9558914085412562
>> elapsed time: 0.437409166 seconds (136 bytes allocated)
>> 1.9558914085412562
>> elapsed time: 0.429992684 seconds (136 bytes allocated)
>> 1.9558914085412367
>> elapsed time: 2.495838008 seconds (136 bytes allocated)
>>
>>
>>
>> 2014-03-01 19:50 GMT+01:00 Ivar Nesje :
>> >
>> > Why do you care for the performance of sin of big integers? I got about 
>> 2 time difference with your test function, but when I did the test with 1.2 
>> as the constant value to take sin of and got.
>> >
>> > julia> function test1()
>> >const N=1000;
>> >@time begin
>> >s = 0.0
>> >for i=1:N
>> >s+= ccall((:sin,"libc"),Float64,(Float64,),1.2) 
>> >end
>> >println(s)
>> >end
>> >@time begin
>> >s = 0.0
>> >for i=1:N
>> >s += sin(1.2)
>> >end
>> >println(s)
>> >end
>> >end
>> > test1 (generic function with 1 method)
>> >
>> > julia> test1()
>> > 9.320390858253522e6
>> > elapsed time: 1.071002334 seconds (168 bytes allocated)
>> > 9.320390858253522e6
>> > elapsed time: 0.930658493 seconds (168 bytes allocated)
>> >
>> >
>> > It would be expected that the native sin function in Julia would be 
>> slower than ccall to libc, because we check the return value to raise an 
>> exception (instead of a NaN value).
>> >
>> > We also use openlibm for our math functions, and the perform

Re: [julia-users] Re: slow trigonometric functions with respect to libc counterpart

[Andrea Pagnani]

Ok, now it makes more sense

function test4()

const N=1
const delta = 2pi / N

@time begin
s = 0.0
for i=0.0:delta:2pi
s+= ccall((:sin,"libc"),Float64,(Float64,),i) 
end
println(s)
end
@time begin
s = 0.0
for i=0.0:delta:2pi
s += sin(i)
end
println(s)
end
end

returns
julia> test4()
7.00424467945944e-9
elapsed time: 1.63142133 seconds (352 bytes allocated)
7.034712528404704e-9
elapsed time: 1.912202446 seconds (352 bytes allocated)


Which makes a lot more sense. The point is in the large numbers involved in 
the computation which, I agree, are not very frequent as argument of 
trigonometric functions. Yet good old libc performs amazingly well.

On Saturday, March 1, 2014 10:24:55 PM UTC+1, Ivar Nesje wrote:
>
> I did say "big integers" in the sense "sin(x) where x > 2pi" not BigInt. I 
> should have said numbers instead of integers. I think part of the problem 
> is that openlibm might do a better job to get high precision with large 
> numbers (> 2pi) than your regular libm installation. You can also see that 
> libm and openlibm does not agree on the last 3 digits. Can you try to 
> benchmark sin of numbers less than 100?
>
> How did you get Julia? If downloaded a nightly distribution, you might 
> also get a less optimized version of openlibm that gives worse performance, 
> than what I am seeing.
>
> Ivar
>
> kl. 21:54:14 UTC+1 lørdag 1. mars 2014 skrev Andrea Pagnani følgende:
>>
>> Hi Ivar, 
>>
>> I tried your version on my system (which I called test2.jl) and
>> julia> test2()
>> 1.9558914085412562
>> elapsed time: 0.31957987 seconds (23456 bytes allocated)
>> 1.9558914085412367
>> elapsed time: 1.488734269 seconds (136 bytes allocated)
>> 1.9558914085412367
>> elapsed time: 1.549758093 seconds (136 bytes allocated)
>>
>> Some misconfiguration on my system?
>>
>> Also it does not seems to be something related to BigInt as
>>
>> function test3()
>>
>> const N=1000;
>> @time begin
>> s = 0.0
>> for i=1.0:1.0:float64(N)
>> s+= ccall((:sin,"libc"),Float64,(Float64,),i) 
>> end
>> println(s)
>> end
>> @time begin
>> s = 0.0
>> for i=1.0:1.0:float64(N)
>> s += sin(i)
>> end
>> println(s)
>> end
>> end
>>
>> Now everything is Float64, yet
>>
>> julia> test3()
>> 1.9558914085412562
>> elapsed time: 0.321183789 seconds (320 bytes allocated)
>> 1.9558914085412367
>> elapsed time: 1.521137678 seconds (320 bytes allocated)
>>
>>
>>
>>
>> On Saturday, March 1, 2014 8:19:05 PM UTC+1, Ivar Nesje wrote:
>>>
>>> Andreas: You compare libopenlibm to the system libm
>>>
>>> function test1()
>>>const N=1000;
>>>@time begin
>>>s = 0.0
>>>for i=1:float(N)
>>>s+= ccall((:sin,"libc"),Float64,(Float64,),i)
>>>end
>>>println(s)
>>>end
>>>@time begin
>>>s = 0.0
>>>for i=1:float(N)
>>>s+= 
>>> Base.nan_dom_err(ccall((:sin,"libopenlibm"),Float64,(Float64,),i),i)
>>>end
>>>println(s)
>>>end
>>>@time begin
>>>s::Float64 = 0.0
>>>for i=1:float(N)
>>>s += sin(i)
>>>end
>>>println(s)
>>>end
>>>end
>>> test1 (generic function with 1 method)
>>>
>>> does not give a significant difference between the built in `sin` 
>>> function and ccall.
>>>
>>> Ivar
>>>
>>>
>>> kl. 19:57:03 UTC+1 lørdag 1. mars 2014 skrev Andreas Noack Jensen 
>>> følgende:
>>>>
>>>> But it is weird that if the definition from math.jl is added such that
>>>>
>>>> function test1()
>>>> const N=1000;
>>>> @time begin
>>>> s = 0.0
>>>> for i=1:float(N)
>>>> s+= ccall((:sin,"libc"),Float64,(Float64,),i)
>>>> end
>>>> println(s)
>>>> end
>>>> @t

[julia-users] Re: How to see the list of defined variables?

[Andrea Pagnani]

whose()

On Monday, March 10, 2014 8:12:39 AM UTC+1, Freddy Chua wrote:
>
> In matlab, I can type "who" to see the defined variables in the workspace.
>
> What do I type in Julia?
>

[julia-users] Re: How to see the list of defined variables?

[Andrea Pagnani]

whos() and not whose() sorry



On Monday, March 10, 2014 8:12:39 AM UTC+1, Freddy Chua wrote:
>
> In matlab, I can type "who" to see the defined variables in the workspace.
>
> What do I type in Julia?
>

Re: [julia-users] Re: Scientific papers using Julia

[Andrea Pagnani]

I do not see the rationale behind splitting papers using Julia into free 
and not free journals. In any case I really  think that having a fair 
representation on what is scientific usage of Julia, could be beneficial 
both to developers and a source of inspiration for potential users.

A

On Friday, March 21, 2014 9:52:14 PM UTC+1, Ivar Nesje wrote:
>
> 3 sections is appropriate
> * About Julia
> * Using Julia
> * Using Julia, but non free access (if we are going to list those at all).
>
> kl. 21:40:37 UTC+1 fredag 21. mars 2014 skrev Stefan Karpinski følgende:
>>
>> I think we should split the publications page into two sections: papers 
>> about Julia at the top and papers using Julia below.
>>
>>
>> On Fri, Mar 21, 2014 at 4:35 PM, Tobias Knopp 
>> wrote:
>>
>>> At some point we probably should start thinking about initiating a 
>>> scientific journal around Julia.
>>> There might be already enough momentum for such a thing given how many 
>>> academic people are around here.
>>>
>>> Am Freitag, 21. März 2014 21:17:43 UTC+1 schrieb Isaiah:

 Could just use existing Publications page and add categories "About 
 Julia" vs "Using Julia"

 There's also: http://ieee-hpec.org/2013/index_htm_files/49.pdf (which 
 falls somewhere between the two categories)


 On Fri, Mar 21, 2014 at 4:08 PM, Jonathan Malmaud wrote:

> Ya, that 
> works.
>  
> Out of the published papers that use Julia for numeric computing, and 
> cite 
> the main Julia paper, we have
>
>
>- Foulds, James, et al. "Stochastic collapsed variational Bayesian 
>inference for latent Dirichlet allocation." *Proceedings of the 
>19th ACM SIGKDD international conference on Knowledge discovery and 
> data 
>mining*. ACM, 2013.
>- Tran, M-N., et al. "Annealed Important Sampling for Models with 
>Latent Variables." *arXiv preprint arXiv:1402.6035* (2014).
>- Picchini, Umberto, and Julie Lyng Forman. "Accelerating 
>inference for diffusions observed with measurement error and large 
> sample 
>sizes using Approximate Bayesian Computation: A case study." *arXiv 
>preprint arXiv:1310.0973* (2013).
>- Lin, Dahua. "Online Learning of Nonparametric Mixture Models via 
>Sequential Variational Approximation." *Advances in Neural 
>Information Processing Systems*. 2013.
>
> So all machine-learning. Might be cool to maintain a list somewhere 
> for marketing purposes.
>
> On Friday, March 21, 2014 11:30:34 AM UTC-7, Ivar Nesje wrote:
>>
>> I realised that about 10 seconds after pushing send. Strange how 
>> doing something irreversible clears the mind. You might search for 
>> citations of those two papers.
>>
>> Ivar
>>
>> kl. 19:19:11 UTC+1 fredag 21. mars 2014 skrev Jonathan Malmaud 
>> følgende:
>>>
>>> Well, those are papers about Julia. I meant papers that just use 
>>> Julia as an implementation language in the course of doing other 
>>> research. 
>>> Sorry for not being clear.
>>>
>>> On Friday, March 21, 2014 11:10:12 AM UTC-7, Ivar Nesje wrote:

 It is prominently placed on our homepage: http://julialang.org/
 publications/

 Ivar

 kl. 19:07:40 UTC+1 fredag 21. mars 2014 skrev Jonathan Malmaud 
 følgende:
>
> Is someone curating a list somewhere of published work that uses 
> Julia? 
>


>>

Re: [julia-users] How can Julia recognise the degree of a polynomial?

[Andrea Pagnani]

Strange behavior

I define Type Polynomial according to Stefan definition and 

julia> a = tuple(rand(500,1)...); b = tuple(rand(500,1)...);

julia> @time P1=Polynomial(a);
elapsed time: 24.441438322 seconds (614490296 bytes allocated)

julia> @time P2=Polynomial(b);
elapsed time: 2.4303e-5 seconds (7296 bytes allocated)

julia> @time P1 + P2;
elapsed time: 0.001270669 seconds (1037376 bytes allocated)

 
 
I tried with a tuple of 1000 random elements on my macBook Pro 4 Giga and 
it takes forever (and starts swapping). It seems that the compiler does not 
handle very well this Type (after the first round type definition for P1, 
creating P2 is super fast, and uses a reasonable amount of memory).

Of course one can use other strategies for polynomials, but the behaviour 
is somehow surprising.

 


 

On Friday, May 2, 2014 5:55:50 PM UTC+2, Stefan Karpinski wrote:
>
> There isn't a built-in polynomial type, but it's pretty easy to make one. 
> If the type of the polynomial depends on its degree, then you can dispatch 
> on it. For example, you could do something like this:
>
> immutable Polynomial{n,T<:Number}
>   a::NTuple{n,T}
> end
> Polynomial(a::Number...) = Polynomial(promote(a...))
>
> function +{d1,d2}(p1::Polynomial{d1}, p2::Polynomial{d2})
> d1 <= d2 || return p2 + p1
> a = ntuple(d2) do k
> k <= d1 ? p1.a[k] + p2.a[k] : p2.a[k]
> end
> Polynomial(promote(a...))
> end
>
> julia> p1 = Polynomial(1,2,3)
> Polynomial{3,Int64}((1,2,3))
>
> julia> p2 = Polynomial(1,2)
> Polynomial{2,Int64}((1,2))
>
> julia> p3 = Polynomial(1,1.5)
> Polynomial{2,Float64}((1.0,1.5))
>
> julia> p1 + p2
> Polynomial{3,Int64}((2,4,3))
>
> julia> p1 + p3
> Polynomial{3,Float64}((2.0,3.5,3.0))
>
> julia> p3 + p1
> Polynomial{3,Float64}((2.0,3.5,3.0))
>
> julia> p3 + p2
> Polynomial{2,Float64}((2.0,3.5))
>
>
> Since the degree of the polynomial is part of the type, you can dispatch 
> based on it. I'm not sure that's necessary though. You could always just 
> check what the degree of a polynomial is and choose between algorithms 
> explicitly.
>
>
> On Fri, May 2, 2014 at 11:25 AM, Albert Díaz 
> > wrote:
>
>> We are trying to develop a program to find the different roots of a nth 
>> degree polynomial using a few quite simple methods (fixed-point, bisection, 
>> newton..) and we would like to know how, when given a function, to 
>> recognise it's degree in order to choose between different root-finding 
>> methods.
>>
>>
>> Thanks 
>>
>
>

[julia-users] LLVM error?

[Andrea Pagnani]

Dear All,

fresh new 0.5

Version 0.5.0-dev+3224 (2016-03-22 14:53 UTC)
Commit 013e0fe* (0 days old master)
x86_64-apple-darwin15.4.0


after a using PyPlot julia exit with a 

LLVM ERROR: Program used external function '_julia_getindex_23789' which 
could not be resolved!

Just to check if it is a known problem before submitting a bug report 

Re: [julia-users] LLVM error?

[Andrea Pagnani]

Ok thanks!

On Tuesday, March 22, 2016 at 5:30:40 PM UTC+1, Isaiah wrote:
>
> Yes, known. See 
> https://github.com/JuliaLang/julia/pull/15300
> https://github.com/JuliaLang/julia/issues/15533
>
>
> On Tue, Mar 22, 2016 at 12:28 PM, Andrea Pagnani  > wrote:
>
>> Dear All,
>>
>> fresh new 0.5
>>
>> Version 0.5.0-dev+3224 (2016-03-22 14:53 UTC)
>> Commit 013e0fe* (0 days old master)
>> x86_64-apple-darwin15.4.0
>>
>>
>> after a using PyPlot julia exit with a 
>>
>> LLVM ERROR: Program used external function '_julia_getindex_23789' which 
>> could not be resolved!
>>
>> Just to check if it is a known problem before submitting a bug report 
>>
>>
>>
>

[julia-users] julia-emacs ...

[Andrea Pagnani]

Dear all,

I discovered that emacs support that after #15694 
 has its own repository.

After a Pkg.update()  in 0.5 I tried: 

Pkg.add("julia-emacs") #no success
Pkg.clone("https://github.com/JuliaLang/julia-emacs";) #no success
Pkg.clone("https://github.com/JuliaLang/julia-emacs.git";) #no success either

Anybody knows what am I doing wrong?

Thanks

Re: [julia-users] julia-emacs ...

[Andrea Pagnani]

Ok ... so just a 

git clone https://github.com/JuliaLang/julia-emacs

makes the job + changing the path of where the julia-mode.el is in the 
.emacs file.

Thanks, and sorry for the noise.

A
On Monday, April 4, 2016 at 11:21:41 AM UTC+2, Stefan Karpinski wrote:
>
> The julia-emacs repo is not a Julia package – the julia package manager 
> doesn't install emacs modes. The julia-emacs repo has some brief 
> instruction on how to install the mode: 
> https://github.com/JuliaLang/julia-emacs#install.
>
> On Mon, Apr 4, 2016 at 5:02 AM, Andrea Pagnani  > wrote:
>
>> Dear all,
>>
>> I discovered that emacs support that after #15694 
>> <https://github.com/JuliaLang/julia/issues/15694> has its own repository.
>>
>> After a Pkg.update()  in 0.5 I tried: 
>>
>> Pkg.add("julia-emacs") #no success
>> Pkg.clone("https://github.com/JuliaLang/julia-emacs";) #no success
>> Pkg.clone("https://github.com/JuliaLang/julia-emacs.git";) #no success 
>> either
>>
>> Anybody knows what am I doing wrong?
>>
>> Thanks
>>
>>
>

[julia-users] Re: Getting the name of the running program

[Andrea Pagnani]

If with name of the program you mean the name of the file where the 
function is defined

 println(@__FILE__)

makes the job.

On Friday, April 8, 2016 at 10:53:14 AM UTC+2, Ferran Mazzanti wrote:
>
> Hi folks,
>
> probably a most stupid question here :) Is there a way to get a string 
> with the name of the Julia program one is running? 
> I ask because I usually write output files starting with a header stating 
> something like "# Results generated by the program " followed by the 
> program name. So how could I get the name of the program I'm running?
>
> Best regards and thanks,
>
> Ferran.
>

[julia-users] scope of variable in parallel reduction ... change from 0.4 to master: bug or feature?

[Andrea Pagnani]

I find the following difference from 0.4 and master. Consider the simple 
function: 

```
function test()
res = @parallel hcat for i = 1:10
if true
i
end
end
res

end
```

on julia0.4 I get

julia> test()
1x10 Array{Int64,2}:
 1  2  3  4  5  6  7  8  9  10

which I think should be the desired output, while on master on master

julia> test()
1x10 Array{Void,2}:
 nothing  nothing  nothing  nothing  nothing  nothing  nothing  nothing 
 nothing  nothing

What do you think?

Re: [julia-users] scope of variable in parallel reduction ... change from 0.4 to master: bug or feature?

[Andrea Pagnani]

Ok ... I trust you that 15188 is related to this. 

Looking forward 15188 to be merged then.

Thanks a lot.


On Tuesday, February 23, 2016 at 12:42:33 PM UTC+1, Yichao Yu wrote:
>
> On Tue, Feb 23, 2016 at 6:06 AM, Andrea Pagnani 
> > wrote: 
> > I find the following difference from 0.4 and master. Consider the simple 
> > function: 
> > 
> > ``` 
> > function test() 
> > res = @parallel hcat for i = 1:10 
> > if true 
> > i 
> > end 
> > end 
> > res 
> > 
> > end 
> > ``` 
> > 
> > on julia0.4 I get 
> > 
> > julia> test() 
> > 1x10 Array{Int64,2}: 
> >  1  2  3  4  5  6  7  8  9  10 
> > 
> > which I think should be the desired output, while on master on master 
> > 
> > julia> test() 
> > 1x10 Array{Void,2}: 
> >  nothing  nothing  nothing  nothing  nothing  nothing  nothing  nothing 
> > nothing  nothing 
> > 
> > What do you think? 
>
> https://github.com/JuliaLang/julia/pull/15188 
>
> > 
> > 
> > 
>

Re: [julia-users] scope of variable in parallel reduction ... change from 0.4 to master: bug or feature?

[Andrea Pagnani]

Just to say that now that 15188 has been merged it works again on master!

Thanks a lot again



On Tuesday, February 23, 2016 at 1:35:51 PM UTC+1, Andrea Pagnani wrote:
>
> Ok ... I trust you that 15188 is related to this. 
>
> Looking forward 15188 to be merged then.
>
> Thanks a lot.
>
>
> On Tuesday, February 23, 2016 at 12:42:33 PM UTC+1, Yichao Yu wrote:
>>
>> On Tue, Feb 23, 2016 at 6:06 AM, Andrea Pagnani 
>>  wrote: 
>> > I find the following difference from 0.4 and master. Consider the 
>> simple 
>> > function: 
>> > 
>> > ``` 
>> > function test() 
>> > res = @parallel hcat for i = 1:10 
>> > if true 
>> > i 
>> > end 
>> > end 
>> > res 
>> > 
>> > end 
>> > ``` 
>> > 
>> > on julia0.4 I get 
>> > 
>> > julia> test() 
>> > 1x10 Array{Int64,2}: 
>> >  1  2  3  4  5  6  7  8  9  10 
>> > 
>> > which I think should be the desired output, while on master on master 
>> > 
>> > julia> test() 
>> > 1x10 Array{Void,2}: 
>> >  nothing  nothing  nothing  nothing  nothing  nothing  nothing  nothing 
>> > nothing  nothing 
>> > 
>> > What do you think? 
>>
>> https://github.com/JuliaLang/julia/pull/15188 
>>
>> > 
>> > 
>> > 
>>
>