Re: [julia-users] Re: dispatch on type of tuple from ...

['Greg Plowman' via julia-users]

I saw your repost on julia-dev, but replying here.

m2 won't work because it expects a series of tuple arguments (which if 
supplied would slurp up into a tuple of tuples).

m3 seems the way to go. 

I wouldn't necessarily look at it as indirect however.
Think of it as one function with 2 methods: one version is for a single 
tuple argument, the other is for the equivalent expressed as 
multiple arguments.
Also, you can define the 2 versions as m3 rather than m3 and _m3.

In fact you could use dispatch to add error processing with a third method:

module Foos
type Foo{T <: Tuple}
end
m4{T<:Tuple}(f::Foo{T}, index::Tuple) = error("expected index type $T, 
got $(typeof(index))")
m4{T<:Tuple}(f::Foo{T}, index::T) = 42
m4(f::Foo, index...) = m4(f, index)
end

f1 = Foos.Foo{Tuple{Int}}()
Foos.m4(f1, 9)

f2 = Foos.Foo{Tuple{Int,Symbol}}()
Foos.m4(f2, (9, :a))
Foos.m4(f2, 9, :a)

Foos.m4(f2, (9.0, :a))  # error, wrong types
Foos.m4(f2, 9.0, :a)# error, wrong types



On Thursday, March 31, 2016 at 1:41:56 AM UTC+11, Tamas Papp wrote:

> Hi Bill, 
>
> It works for a single argument, but not for multiple ones. I have a 
> self-contained example: 
>
> --8<---cut here---start->8--- 
> module Foos 
>
> type Foo{T <: Tuple} 
> end 
>
> m1{T}(f::Foo{Tuple{T}}, index::T...) = 42 # suggested by Bill Hart 
>
> m2{T}(f::Foo{T}, index::T...) = 42 # what I thought would work 
>
> _m3{T}(f::Foo{T}, index::T) = 42 # indirect solution 
> m3{T}(f::Foo{T}, index...) = _m3(f, index) 
>
> end 
>
> f1 = Foos.Foo{Tuple{Int}}() 
>
> Foos.m1(f1, 9)  # works 
> Foos.m2(f1, 9)  # won't work 
> Foos.m3(f1, 9)  # works 
>
> f2 = Foos.Foo{Tuple{Int,Symbol}}() 
>
> Foos.m1(f2, 9, :a)   # won't work 
> Foos.m2(f2, 9, :a)   # won't work 
> Foos.m3(f2, 9, :a)   # indirect, works 
> --8<---cut here---end--->8--- 
>
> For more than one argument, only the indirect solution works. 
>
> Best, 
>
> Tamas 
>
> On Wed, Mar 23 2016, via julia-users wrote: 
>
> > The following seems to work, but I'm not sure whether it was what you 
> > wanted: 
> > 
> > import Base.getindex 
> > 
> > type Foo{T <: Tuple} 
> > end 
> > 
> > getindex{T}(f::Foo{Tuple{T}}, index::T...) = 42 
> > 
> > Foo{Tuple{Int}}()[9] 
> > 
> > Bill. 
> > 
> > On Wednesday, 23 March 2016 14:38:20 UTC+1, Tamas Papp wrote: 
> >> 
> >> Hi, 
> >> 
> >> My understanding was that ... in a method argument forms a tuple, but I 
> >> don't know how to dispatch on that. Self-contained example: 
> >> 
> >> import Base.getindex 
> >> 
> >> type Foo{T <: Tuple} 
> >> end 
> >> 
> >> getindex{T}(f::Foo{T}, index::T...) = 42 
> >> 
> >> Foo{Tuple{Int}}()[9] ## won't match 
> >> 
> >> ## workaround with wrapper: 
> >> 
> >> _mygetindex{T}(f::Foo{T}, index::T) = 42 
> >> mygetindex{T}(f::Foo{T}, index...) = _mygetindex(f, index) 
> >> 
> >> mygetindex(Foo{Tuple{Int}}(), 9) 
> >> 
> >> Is it possible to make it work without a wrapper in current Julia? 
> >> 
> >> Best, 
> >> 
> >> Tamas 
> >> 
>
>

[julia-users] Re: Julia console with inline graphics?

[Lanfeng Pan]

There is qtconsole to display inline images. 
 

On Saturday, April 2, 2016 at 5:45:22 AM UTC-5, Oliver Schulz wrote:
>
> Hi,
>
> I'm looking for a Julia console with inline graphics (e.g. to display 
> Gadfly plots). There's Jupyter/IJulia, of course, but I saw a picture of 
> something more console-like in the AxisArrays readme (at the end of 
> https://github.com/mbauman/AxisArrays.jl#example-of-currently-implemented-behavior)
>  
> - does anyone know what's been used there?
>
> Cheers,
>
> Oliver
>
>

Re: [julia-users] dispatch slowdown when iterating over array with abstract values

['Greg Plowman' via julia-users]

Thanks for your replies. 
I'm sorry to trouble you again, but I'm still confused about general 
concepts.

It seems to me that slowness of dynamic dispatch and type instability are 
orthogonal.
I mean is dynamic dispatch inherently slow, or is it slow because it 
involves type instability?

@code_warntype slow(features) suggests that the return type from evaluate() 
is Float64, so I can't see any type instability.
If this is correct, then why is dynamic dispatch so much slower than 
run-time if statements?

For my own understanding, I was almost hoping that slow() was not 
type-stable, 
and annotating with evaluate(features[i])::Float64 would let the compiler 
produce faster code,
but it makes no difference.


On Sunday, April 3, 2016 at 11:07:44 PM UTC+10, Cedric St-Jean wrote:

> Good call, it was already pointed ou 
> t in 
> that thread.
>
> On Sat, Apr 2, 2016 at 11:11 PM, Yichao Yu  > wrote:
>
>> On Sat, Apr 2, 2016 at 10:53 PM, Cedric St-Jean > > wrote:
>> > That's actually a compiler bug, nice!
>> >
>> > abstract Feature
>> >
>> > type A <: Feature end
>> > evaluate(f::A) = 1.0
>> >
>> > foo(features::Vector{Feature}) = isa(features[1], A) ?
>> > evaluate(features[1]::A) : evaluate(features[1])
>> >
>> > @show foo(Feature[A()])
>> >
>> > type C <: Feature end
>> > evaluate(f::C) = 100
>> >
>> > @show foo(Feature[C()])
>> >
>> > yields
>> >
>> > foo(Feature[A()]) = 1.0
>> >
>> > foo(Feature[C()]) = 4.94e-322
>> >
>> >
>> > That explains why performance was the same on your computer: the 
>> compiler
>> > was making an incorrect assumption about the return type of `evaluate`. 
>> Or
>> > maybe it's an intentional gamble by the Julia devs, for the sake of
>> > performance.
>> >
>> > I couldn't find any issue describing this. Yichao?
>>
>> This is effectively #265. It's not always predictable what assumption
>> the compiler makes now...
>>
>> >
>> >
>> > On Saturday, April 2, 2016 at 10:16:59 PM UTC-4, Greg Plowman wrote:
>> >>
>> >> Thanks Cedric and Yichao.
>> >>
>> >> This makes sense that there might be new subtypes and associated
>> >> specialised methods. I understand that now. Thanks.
>> >>
>> >> On my machine (v0.4.5 Windows), fast() and pretty_fast() seem to run in
>> >> similar time.
>> >> So I looked as @code_warntype as Yichao suggested and get the 
>> following.
>> >> I don't fully know how to interpret output, but return type from the 
>> final
>> >> "catchall" evaluate() seems to be inferred/asserted as Float64 (see
>> >> highlighted yellow line below)
>> >>
>> >> Would this explain why pretty_fast() seems to be as efficient as 
>> fast()?
>> >>
>> >> Why is the return type being inferred asserted as Float64?
>> >>
>> >>
>> >> julia> @code_warntype fast(features)
>> >> Variables:
>> >>   features::Array{Feature,1}
>> >>   retval::Float64
>> >>   #s1::Int64
>> >>   i::Int64
>> >>
>> >> Body:
>> >>   begin  # none, line 2:
>> >>   retval = 0.0 # none, line 3:
>> >>   GenSym(2) = (Base.arraylen)(features::Array{Feature,1})::Int64
>> >>   GenSym(0) = $(Expr(:new, UnitRange{Int64}, 1,
>> >> 
>> :(((top(getfield))(Base.Intrinsics,:select_value)::I)((Base.sle_int)(1,GenSym(2))::Bool,GenSym(2),(Base.box)
>> >> (Int64,(Base.sub_int)(1,1)))::Int64)))
>> >>   #s1 = (top(getfield))(GenSym(0),:start)::Int64
>> >>   unless (Base.box)(Base.Bool,(Base.not_int)(#s1::Int64 ===
>> >> 
>> (Base.box)(Base.Int,(Base.add_int)((top(getfield))(GenSym(0),:stop)::Int64,1))::Bool))
>> >> goto 1
>> >>   2:
>> >>   GenSym(3) = #s1::Int64
>> >>   GenSym(4) = (Base.box)(Base.Int,(Base.add_int)(#s1::Int64,1))
>> >>   i = GenSym(3)
>> >>   #s1 = GenSym(4) # none, line 4:
>> >>   unless
>> >> 
>> (Main.isa)((Base.arrayref)(features::Array{Feature,1},i::Int64)::Feature,Main.A)::Bool
>> >> goto 4 # none, line 5:
>> >>   retval =
>> >> (Base.box)(Base.Float64,(Base.add_float)(retval::Float64,1.0))
>> >>   goto 5
>> >>   4:  # none, line 7:
>> >>   retval =
>> >> (Base.box)(Base.Float64,(Base.add_float)(retval::Float64,0.0))
>> >>   5:
>> >>   3:
>> >>   unless
>> >> 
>> (Base.box)(Base.Bool,(Base.not_int)((Base.box)(Base.Bool,(Base.not_int)(#s1::Int64
>> >> === (Base.box)(Base.Int,(Base.add_int)((top(getfield))(GenSym(0)
>> >> ,:stop)::Int64,1))::Bool goto 2
>> >>   1:
>> >>   0:  # none, line 10:
>> >>   return retval::Float64
>> >>   end::Float64
>> >>
>> >>
>> >> julia> @code_warntype pretty_fast(features)
>> >> Variables:
>> >>   features::Array{Feature,1}
>> >>   retval::Float64
>> >>   #s1::Int64
>> >>   i::Int64
>> >>
>> >> Body:
>> >>   begin  # none, line 2:
>> >>   retval = 0.0 # none, line 3:
>> >>   GenSym(2) = (Base.arraylen)(features::Array{Feature,1})::Int64
>> >>   GenSym(0) = $(Expr(:new, UnitRange{Int64}, 1,
>> >> 
>> 

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

[Cristóvão Duarte Sousa]

> Decisions that in my opinion were made by people who do not write 
research-code:
> 1. Indexing in Julia. being 1 based and inclusive, instead of 0 based and 
not including the end (like in c/python/lots of other stuff)
> 2. No simple integer-division operator.

I do not understand why this is related to research code. In fact, if it 
would ever be then I think it would be exactly the other way around, more 
close to basic mathematics: stuff gets enumerated as 1st, 2nd, etc., and a 
division of two integer numbers may give non-integral results!

Curiously for me, who only knew C, C++ and Python for many years, the 
0-based indexing never made any "mathematical" sense.
I always have seen it as a useful hack to do pointer arithmetic. Although 
it enables shorter code, I always had the need to do a mental conversion 
between what the algorithm looks like in my head and how it must look like 
in the source code.

When I first learn Julia the 1-based indexing just felt so natural! 
However, I think this is really an issue that cannot make a language better 
or worse. In the end, it will be a lot more related to programmer 
familiarness and personal preference than something else.



On Saturday, April 2, 2016 at 12:55:55 PM UTC+1, Spiritus Pap wrote:
>
> Hi there,
>
> TL;DR: A lot of people that could use julia (researchers currently using 
> python) won't. I give an example of how it makes my life hard, and I try to 
> suggest solutions.
>
> Iv'e been introduced to julia about a month ago.
> I'm an algorithmic researcher, I write mostly research code: statistics, 
> image processing, algorithms, etc.
> I use mostly python with numpy for my stuff, and C/++ when I need 
> performance.
> I was really happy when I heard of julia, because it takes the simplicity 
> of python and combines it with JIT compilation for speed!
>
> I REALLY tried to use julia, I really did. I tried to convince my friends 
> at work to use it too.
> However, there are a few things that make it unusable the way it is.
>
> Decisions that in my opinion were made by people who do not write 
> research-code:
> 1. Indexing in Julia. being 1 based and inclusive, instead of 0 based and 
> not including the end (like in c/python/lots of other stuff)
> 2. No simple integer-division operator.
>
> A simple example why it makes my *life hard*: Assume there is an array of 
> size 100, and i want to take the i_th portion of it out of n. This is a 
> common scenario for research-code, at least for me and my friends.
> In python:
> a[i*100/n:(i+1)*100/n]
> In julia:
> a[1+div(i*100,n):div((i+1)*100,n)]
>
> A lot more cumbersome in julia, and it is annoying and unattractive. This 
> is just a simple example.
>
> *Possible solutions:*
> The reason I'm writing this post is because I want to use julia, and I 
> want to to become great.
> *About the division:* I would suggest *adding *an integer division 
> *operator*, such as *//*. Would help a lot. Yes, I think it should be by 
> default, so that newcomers would need the least amount of effort to use 
> julia comfortably.
>
> *About the indexing:* I realize that this is a decision made a long time 
> ago, and everything is built this way. Yes, it is like matlab, and no, it 
> is not a good thing.
> I am a mathematician, and I almost always index my sequences expressions 
> in 0, it usually just makes more sense.
> The problem is both in array (e.g. a[0]) and in slice (e.g. 0:10).
> An array could be solved perhaps by a *custom *0 based *array object*. 
> But the slice? Maybe adding a 0 based *slice operator*(such as .. or _)? 
> is it possible to do so in a library?
>
> I'd be happy to write these myself, but I believe these need to be in the 
> standard library. Again, so that newcomers would need the least amount of 
> effort to use julia comfortably.
> If you have better suggestions, I'd be happy to hear.
>
> Thank you for your time
>

Re: [julia-users] List comprehension for 1 <= i < j <= 4

[Erik Schnetter]

Nothing has been set in stone, but one proposed syntax is

```Julia
l = collect((i, j) for j in range(i+1, 5) for i in range(1, 5))
```

i.e. using parentheses instead of brackets, exchanging the order of
`i` and `j`, and using an explicit call to `collect` to convert the
generator into an array. Without that call, you get a generator that
is more efficient since it doesn't have to allocate memory -- compare
`range` and `xrange` in Python 2. In most circumstances, you would be
able to use the generator directly instead of having to convert it to
an array, and then you don't need the call to `collect.

-erik



On Sun, Apr 3, 2016 at 1:25 PM, Jonatan Pallesen  wrote:
> Performance is not the main factor. More importantly I don't think the vcat
> solution looks very neat. I'm curious about what the proposed generator
> syntax is.



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

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

[Chris Rackauckas]

I came to this thinking it would be about how Julia pedagogy is a little 
more difficult than other scripting languages because there are a lot of 
details in the advanced features which are normally the points of 
conversation for more experienced users. That's a legitimate concern.

However, this is simply not willing to adapt. I also enjoy Julia's choice 
for "/" to return a float. Julia will yell at me if I needed an integer, 
and then I just do "\di[Tab]" and that completes it. The other way around, 
"/" silently returns an integer and your code keeps working even if that's 
not what you meant, leads to many issues! I like that the point of types in 
Julia is to help you keep your data intact (and give you errors when there 
are potential problems), unlike in lower level languages where they exist 
because you need to tell the compiler how to work. And caring about 0 vs 1 
indexing is... just subtract 1.

Re: [julia-users] Re: Large number of methods for a function and Julia for data acquisition

[Oliver Schulz]

So, since we got you on this thread, Stefan - what's your take on the 
original question? :-)

I mean, is it Ok to have (potentially) thousands of methods for getindex 
and setindex, or will this have serious consequences for compile time 
and/or dynamic dispatch situations?

On Sunday, April 3, 2016 at 6:57:23 PM UTC+2, Stefan Karpinski wrote:
>
> No worries. I just wanted to provide a link for context.
>
> On Sun, Apr 3, 2016 at 12:49 PM, Oliver Schulz  > wrote:
>
>> Oh, darn - sorry, Stefan. I wanted to change the topic since the 
>> discussion had moved quite a bit from the original question, but I didn't 
>> consider email clients.
>>
>> On Sunday, April 3, 2016 at 2:06:06 PM UTC+2, Stefan Karpinski wrote:
>>>
>>> I'm afraid that changing the subject here removes all context for this 
>>> message in most email systems. Groups seems to keep the message in context:
>>>
>>> https://groups.google.com/d/msg/julia-users/Dt6nbfhtaNQ/TCy6zT9HAAAJ
>>>
>>> On Sun, Apr 3, 2016 at 4:34 AM, Oliver Schulz  
>>> wrote:
>>>
 Hi Andrew,

 On Saturday, April 2, 2016 at 7:10:00 PM UTC+2, Andrew Keller wrote:
>
> Regarding your first question posed in this thread, I think you might 
> be interested in this documentation 
>  of how 
> functions will work in Julia 0.5 if you haven't read it already.
>

 Yes, I'm aware that some big changes are coming with 0.5, and many of 
 them (e.g. threads and fast anonymous functions) are of course highly 
 relevant to this kind of application. For now I'm kinda stuck with 0.4 for 
 actual use cases, because so many packages (e.g. PyPlot, Gadfly, ...) have 
 trouble with 0.5 at the moment. But once 0.5 is ready, I will probably not 
 even try to keep things compatible with 0.4, as this is a new project 
 anyway.
  

 I hope you don't mind that I've tried out your setindex and getindex 
> approach. [...] It is very pleasant to use but I have not benchmarked it 
> in 
> any serious way [...] If you'd like me to try out something I'll see what 
> I 
> can do.
>

 Thanks, you're more than welcome! The more the merrier, and this can 
 only profit from wide testing. It would be good to try how this performs 
 with, say, about 500 feature types and 500 device types, each implementing 
 like 100 features. I hope this will still perform well in dynamic dispatch 
 situations - maybe one of the Julia experts can weigh in here?
  

 It sounds like you have probably been thinking deeply about instrument 
> control for a much longer period of time than I have.
>

 Well, thinking and learning a lot from my earlier mistakes. :-)
  

 You can find any number of discussion threads, GitHub issues, etc. on 
> traits in Julia but I don't know what current consensus is.
>

 I did play with some of the current approaches to traits in Julia a 
 while ago (Mauro's and Tim's work), and it's definitely something to watch 
 (I'd love to see something like that in Base some day). For now, I hope we 
 may be able to get by without explicit "device classes".

  

> Thanks for linking to your code. I have no experience with Scala but I 
> will take a look at it.
>

 Don't judge to harshly. :-) This has been a work in progress for many 
 years, and it is in active use for two long-term physics experiments and 
 multiple lab applications - but since it was always driven by our current 
 needs, I often didn't find time to port new ideas and concepts to older 
 portions of the code. One of the goals was always to use it for both 
 high-rate physics DAQ, and low-rate "slow-control"/SCADA applications. I 
 was planning a major overhaul, but recently decided that Julia will be a 
 better platform in the long run for various reasons (one of them that most 
 students don't have time to learn several programming languages, and Scala 
 isn't really an option for our kind of data analysis).

 Implementing specific devices has actually only been a fraction of the 
 work - a large part has always been implementing communication protocols. 
 For various devices, I needed (and implemented) VXI11, Modbus, SNMP, VME 
 (over ethernet bridge), CANOpen (for one speficic gateway), and various 
 vendor specific ASCII and binary protocols (e.g. Pfeiffer vaccum, old 
 Keithley ASCII, etc.). Plus things like an SCPI parser, etc.. I look 
 forward to port all of that to Julia - well, eventually ... ;-)

 I'd like the core to stay pure-Julia, though this will be challenging 
 with VXI11 and SNMP, as there's no native-Julia ONC-RPC or SNMP library. 
 And for devices that really need a vendor-specific VISA driver (because 
 

Re: [julia-users] List comprehension for 1 <= i < j <= 4

[Jonatan Pallesen]

Performance is not the main factor. More importantly I don't think the vcat 
solution looks very neat. I'm curious about what the proposed generator 
syntax is.

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

[Oliver Schulz]

IMHO having the "/" operator return a float was an excellent design 
decision in Julia. The amount of time I've seen people waste (with other 
languages) tracking down bugs caused by doing a/b with a
> I question the alleged ubiquity of integer division. This is not an 
> operation I find myself needing all that often. Of course, everyone's 
> programming needs are different, but I just don't find myself wanting the 
> integer quotient of a and b more often than I want to do a/b and get their 
> ratio as a float.
>
> On Sun, Apr 3, 2016 at 12:09 PM, Tim Holy  > wrote:
>
>> Indexing with // is a bit undesirable because 6//3 gets simplified to 
>> 2//1 upon
>> construction, and there's no reason to pay the cost of that operation.
>>
>> With \\, would you worry about confusion from the fact that in a \\ b, a 
>> is in
>> the denominator? Especially if it gets called the "integer division 
>> operator."
>>
>> One could use ///, but that's starting to be pretty comparable to 
>> \div[TAB],
>> and less pretty to read.
>>
>> --Tim
>>
>>
>> On Sunday, April 03, 2016 05:56:26 AM Scott Jones wrote:
>> > For some reason, my posts are getting sent prematurely!  Continuing:
>> >
>> > Since the integer division operator // of Python (2&3) and Lua already
>> > means something important in Julia, and \ is also taken, I'd like to
>> > propose \\ as an integer division operator for Julia.
>> > Having to always type \ d i v  in the REPL, and something 
>> different in
>> > Emacs, or write things out as `div(a, b)` (6 characters typed!), is 
>> rather
>> > annoying, \\ is just a syntax error currently in Julia
>> > and could easily be added to the parser and made a synonym to div (÷).
>>
>>
>

Re: [julia-users] Re: Large number of methods for a function and Julia for data acquisition

[Stefan Karpinski]

No worries. I just wanted to provide a link for context.

On Sun, Apr 3, 2016 at 12:49 PM, Oliver Schulz  wrote:

> Oh, darn - sorry, Stefan. I wanted to change the topic since the
> discussion had moved quite a bit from the original question, but I didn't
> consider email clients.
>
> On Sunday, April 3, 2016 at 2:06:06 PM UTC+2, Stefan Karpinski wrote:
>>
>> I'm afraid that changing the subject here removes all context for this
>> message in most email systems. Groups seems to keep the message in context:
>>
>> https://groups.google.com/d/msg/julia-users/Dt6nbfhtaNQ/TCy6zT9HAAAJ
>>
>> On Sun, Apr 3, 2016 at 4:34 AM, Oliver Schulz 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Saturday, April 2, 2016 at 7:10:00 PM UTC+2, Andrew Keller wrote:

 Regarding your first question posed in this thread, I think you might
 be interested in this documentation
  of how
 functions will work in Julia 0.5 if you haven't read it already.

>>>
>>> Yes, I'm aware that some big changes are coming with 0.5, and many of
>>> them (e.g. threads and fast anonymous functions) are of course highly
>>> relevant to this kind of application. For now I'm kinda stuck with 0.4 for
>>> actual use cases, because so many packages (e.g. PyPlot, Gadfly, ...) have
>>> trouble with 0.5 at the moment. But once 0.5 is ready, I will probably not
>>> even try to keep things compatible with 0.4, as this is a new project
>>> anyway.
>>>
>>>
>>> I hope you don't mind that I've tried out your setindex and getindex
 approach. [...] It is very pleasant to use but I have not benchmarked it in
 any serious way [...] If you'd like me to try out something I'll see what I
 can do.

>>>
>>> Thanks, you're more than welcome! The more the merrier, and this can
>>> only profit from wide testing. It would be good to try how this performs
>>> with, say, about 500 feature types and 500 device types, each implementing
>>> like 100 features. I hope this will still perform well in dynamic dispatch
>>> situations - maybe one of the Julia experts can weigh in here?
>>>
>>>
>>> It sounds like you have probably been thinking deeply about instrument
 control for a much longer period of time than I have.

>>>
>>> Well, thinking and learning a lot from my earlier mistakes. :-)
>>>
>>>
>>> You can find any number of discussion threads, GitHub issues, etc. on
 traits in Julia but I don't know what current consensus is.

>>>
>>> I did play with some of the current approaches to traits in Julia a
>>> while ago (Mauro's and Tim's work), and it's definitely something to watch
>>> (I'd love to see something like that in Base some day). For now, I hope we
>>> may be able to get by without explicit "device classes".
>>>
>>>
>>>
 Thanks for linking to your code. I have no experience with Scala but I
 will take a look at it.

>>>
>>> Don't judge to harshly. :-) This has been a work in progress for many
>>> years, and it is in active use for two long-term physics experiments and
>>> multiple lab applications - but since it was always driven by our current
>>> needs, I often didn't find time to port new ideas and concepts to older
>>> portions of the code. One of the goals was always to use it for both
>>> high-rate physics DAQ, and low-rate "slow-control"/SCADA applications. I
>>> was planning a major overhaul, but recently decided that Julia will be a
>>> better platform in the long run for various reasons (one of them that most
>>> students don't have time to learn several programming languages, and Scala
>>> isn't really an option for our kind of data analysis).
>>>
>>> Implementing specific devices has actually only been a fraction of the
>>> work - a large part has always been implementing communication protocols.
>>> For various devices, I needed (and implemented) VXI11, Modbus, SNMP, VME
>>> (over ethernet bridge), CANOpen (for one speficic gateway), and various
>>> vendor specific ASCII and binary protocols (e.g. Pfeiffer vaccum, old
>>> Keithley ASCII, etc.). Plus things like an SCPI parser, etc.. I look
>>> forward to port all of that to Julia - well, eventually ... ;-)
>>>
>>> I'd like the core to stay pure-Julia, though this will be challenging
>>> with VXI11 and SNMP, as there's no native-Julia ONC-RPC or SNMP library.
>>> And for devices that really need a vendor-specific VISA driver (because
>>> SCPI over VXI11 is not enough) Instruments.jl (
>>> https://github.com/BBN-Q/Instruments.jl) may come in play (haven't
>>> tried it yet).
>>>
>>> I'd love to work with other people interested in this - Julia is great
>>> at making data analysis fast and easy, not reason it shouldn't be as great
>>> at taking the data in the first place!
>>>
>>>
>>>
 Unitful.jl and SIUnits.jl globally have the same approach [...] My
 package only supports Julia 0.5 though. [...]An open question is how one
 could 

Re: [julia-users] Re: Large number of methods for a function and Julia for data acquisition

[Oliver Schulz]

Oh, darn - sorry, Stefan. I wanted to change the topic since the discussion 
had moved quite a bit from the original question, but I didn't consider 
email clients.

On Sunday, April 3, 2016 at 2:06:06 PM UTC+2, Stefan Karpinski wrote:
>
> I'm afraid that changing the subject here removes all context for this 
> message in most email systems. Groups seems to keep the message in context:
>
> https://groups.google.com/d/msg/julia-users/Dt6nbfhtaNQ/TCy6zT9HAAAJ
>
> On Sun, Apr 3, 2016 at 4:34 AM, Oliver Schulz  > wrote:
>
>> Hi Andrew,
>>
>> On Saturday, April 2, 2016 at 7:10:00 PM UTC+2, Andrew Keller wrote:
>>>
>>> Regarding your first question posed in this thread, I think you might be 
>>> interested in this documentation 
>>>  of how 
>>> functions will work in Julia 0.5 if you haven't read it already.
>>>
>>
>> Yes, I'm aware that some big changes are coming with 0.5, and many of 
>> them (e.g. threads and fast anonymous functions) are of course highly 
>> relevant to this kind of application. For now I'm kinda stuck with 0.4 for 
>> actual use cases, because so many packages (e.g. PyPlot, Gadfly, ...) have 
>> trouble with 0.5 at the moment. But once 0.5 is ready, I will probably not 
>> even try to keep things compatible with 0.4, as this is a new project 
>> anyway.
>>  
>>
>> I hope you don't mind that I've tried out your setindex and getindex 
>>> approach. [...] It is very pleasant to use but I have not benchmarked it in 
>>> any serious way [...] If you'd like me to try out something I'll see what I 
>>> can do.
>>>
>>
>> Thanks, you're more than welcome! The more the merrier, and this can only 
>> profit from wide testing. It would be good to try how this performs with, 
>> say, about 500 feature types and 500 device types, each implementing like 
>> 100 features. I hope this will still perform well in dynamic dispatch 
>> situations - maybe one of the Julia experts can weigh in here?
>>  
>>
>> It sounds like you have probably been thinking deeply about instrument 
>>> control for a much longer period of time than I have.
>>>
>>
>> Well, thinking and learning a lot from my earlier mistakes. :-)
>>  
>>
>> You can find any number of discussion threads, GitHub issues, etc. on 
>>> traits in Julia but I don't know what current consensus is.
>>>
>>
>> I did play with some of the current approaches to traits in Julia a while 
>> ago (Mauro's and Tim's work), and it's definitely something to watch (I'd 
>> love to see something like that in Base some day). For now, I hope we may 
>> be able to get by without explicit "device classes".
>>
>>  
>>
>>> Thanks for linking to your code. I have no experience with Scala but I 
>>> will take a look at it.
>>>
>>
>> Don't judge to harshly. :-) This has been a work in progress for many 
>> years, and it is in active use for two long-term physics experiments and 
>> multiple lab applications - but since it was always driven by our current 
>> needs, I often didn't find time to port new ideas and concepts to older 
>> portions of the code. One of the goals was always to use it for both 
>> high-rate physics DAQ, and low-rate "slow-control"/SCADA applications. I 
>> was planning a major overhaul, but recently decided that Julia will be a 
>> better platform in the long run for various reasons (one of them that most 
>> students don't have time to learn several programming languages, and Scala 
>> isn't really an option for our kind of data analysis).
>>
>> Implementing specific devices has actually only been a fraction of the 
>> work - a large part has always been implementing communication protocols. 
>> For various devices, I needed (and implemented) VXI11, Modbus, SNMP, VME 
>> (over ethernet bridge), CANOpen (for one speficic gateway), and various 
>> vendor specific ASCII and binary protocols (e.g. Pfeiffer vaccum, old 
>> Keithley ASCII, etc.). Plus things like an SCPI parser, etc.. I look 
>> forward to port all of that to Julia - well, eventually ... ;-)
>>
>> I'd like the core to stay pure-Julia, though this will be challenging 
>> with VXI11 and SNMP, as there's no native-Julia ONC-RPC or SNMP library. 
>> And for devices that really need a vendor-specific VISA driver (because 
>> SCPI over VXI11 is not enough) Instruments.jl (
>> https://github.com/BBN-Q/Instruments.jl) may come in play (haven't tried 
>> it yet).
>>
>> I'd love to work with other people interested in this - Julia is great at 
>> making data analysis fast and easy, not reason it shouldn't be as great at 
>> taking the data in the first place!
>>  
>>   
>>
>>> Unitful.jl and SIUnits.jl globally have the same approach [...] My 
>>> package only supports Julia 0.5 though. [...]An open question is how one 
>>> could dispatch on the dimensions (e.g. x::Length).
>>>
>>
>> Ah, right, now I remember - i kinda mixed up SIUnits and Unitful, sorry. 
>> I did give Unitful a quick try when you announced it on the 

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

[Stefan Karpinski]

I question the alleged ubiquity of integer division. This is not an
operation I find myself needing all that often. Of course, everyone's
programming needs are different, but I just don't find myself wanting the
integer quotient of a and b more often than I want to do a/b and get their
ratio as a float.

On Sun, Apr 3, 2016 at 12:09 PM, Tim Holy  wrote:

> Indexing with // is a bit undesirable because 6//3 gets simplified to 2//1
> upon
> construction, and there's no reason to pay the cost of that operation.
>
> With \\, would you worry about confusion from the fact that in a \\ b, a
> is in
> the denominator? Especially if it gets called the "integer division
> operator."
>
> One could use ///, but that's starting to be pretty comparable to
> \div[TAB],
> and less pretty to read.
>
> --Tim
>
>
> On Sunday, April 03, 2016 05:56:26 AM Scott Jones wrote:
> > For some reason, my posts are getting sent prematurely!  Continuing:
> >
> > Since the integer division operator // of Python (2&3) and Lua already
> > means something important in Julia, and \ is also taken, I'd like to
> > propose \\ as an integer division operator for Julia.
> > Having to always type \ d i v  in the REPL, and something different
> in
> > Emacs, or write things out as `div(a, b)` (6 characters typed!), is
> rather
> > annoying, \\ is just a syntax error currently in Julia
> > and could easily be added to the parser and made a synonym to div (÷).
>
>

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

[Tim Holy]

Indexing with // is a bit undesirable because 6//3 gets simplified to 2//1 upon 
construction, and there's no reason to pay the cost of that operation.

With \\, would you worry about confusion from the fact that in a \\ b, a is in 
the denominator? Especially if it gets called the "integer division operator."

One could use ///, but that's starting to be pretty comparable to \div[TAB], 
and less pretty to read.

--Tim


On Sunday, April 03, 2016 05:56:26 AM Scott Jones wrote:
> For some reason, my posts are getting sent prematurely!  Continuing:
> 
> Since the integer division operator // of Python (2&3) and Lua already
> means something important in Julia, and \ is also taken, I'd like to
> propose \\ as an integer division operator for Julia.
> Having to always type \ d i v  in the REPL, and something different in
> Emacs, or write things out as `div(a, b)` (6 characters typed!), is rather
> annoying, \\ is just a syntax error currently in Julia
> and could easily be added to the parser and made a synonym to div (÷).

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

[Eric Forgy]

Just thinking out loud...

On Sunday, April 3, 2016 at 11:49:33 PM UTC+8, Scott Jones wrote:
>
> What do you think about adding \\ as an integer division operator to Julia?
>

What about just writing some package to allow indexing arrays with 
rationals if this is so important to some people? If the denominator is not 
1, it errors or something.

My experience so far with Julia is that if there is a feature you'd like to 
have that is not in Base, it is easy to add that feature in a package and 
see little loss in performance. It should be easy to write a package that 
introduces arrays with index starting at 0 and it should be easy to write a 
package that indexes arrays with rationals so you can just write things 
like a[10//5].

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

[Scott Jones]

I didn't say that it was.  However, I don't think that there is any 
evidence for the statement that: "Python community at large consider to be 
sufficiently much better", given that only around 1/3 of the community even 
uses Python 3 yet.
The big reason (with lots of evidence to support this) was because of all 
the dependencies that no longer worked - Python3 didn't attempt to be 
backwards compatible, and AFAIK didn't have cool tools like Compat.jl to 
help smooth the transition when there are breaking changes.
(I personally only use Python3, because of the much better string support).
It almost seems like Guido might have done better to introduce it as a new 
language, maybe called Viper ;-) given all the incompatibilities.

Integer division is something that is very frequently used, and having an 
easy to use operator in Julia that doesn't require Unicode would be a great 
plus for many people.
What do you think about adding \\ as an integer division operator to Julia?

On Sunday, April 3, 2016 at 10:09:16 AM UTC-4, Stefan Karpinski wrote:
>
> On Sun, Apr 3, 2016 at 8:50 AM, Scott Jones  > wrote:
>
>> Yes, Python3 did switch from 1/2 returning a float, but Python3 still is 
>> having major problems with acceptance from the Python community, so I don't 
>> think that's the best example to use.
>>
>
> The change of division is not the reason people are not using Python 3.
>

Re: [julia-users] List comprehension for 1 <= i < j <= 4

[Erik Schnetter]

On Sun, Apr 3, 2016 at 4:12 AM, Jonatan Pallesen  wrote:
> I want to make a list comprehension for 1 <= i < j <= 4. It can be done with
> a for loop like this:
>
> l = []
> for i in 1:4, j in i+1:4
> push!(l, (i,j))
> end
>
> In python a list comprehension can be made like this
>
> l = [(i, j) for i in range(1, 5) for j in range(i+1, 5)]
>
> But this Julia code gives an error, saying i is not defined:
>
> l = [(i,j) for i in 1:4, j in i+1:4]
>
> Is there another approach? I feel like 4 lines to do this is excessive

Since `i` and `j` are integers, you probably want to initialize the
output array with `Int[]`. This will improve performance.

In Python, a comprehension yields a one-dimensional array, hence
ragged loop boundaries are possible. In Julia, this syntax gives you a
two-dimensional array, hence the loop ranges cannot depend on each
other. The reason things were designed that way is that, in Python, a
list (a one-dimensional array) is the "natural" data structure,
whereas in Julia, a multi-dimensional array is "natural".

Currently, the for loop you showed is the best way to do this. There
is a discussion about generators and appropriate syntax on the
development mailing list, but this isn't ready for testing yet.

The `vcat` solution suggested below is slower since it creates several
intermediate arrays and then concatenates them; this might or might
not be important to you.

-erik

-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] How to pass ARGS to a script inside julia

[Yichao Yu]

On Sun, Apr 3, 2016 at 9:16 AM, Gino Serpa  wrote:
> Hi,
> I know that I can pass arguments to a script using ARGS and then just
> running from the console  prompt  as in
>
>> julia test01.jl 2048
>
> where the argument 2048 is passed to test01.jl. But what if I want to pass
> this argument inside julia to the same script

In general, you should arrange your code so that you can run the code
in the script by calling a function. We don't have particularly good
support for using a file both as a script and as a code to include yet
but you can still split out the actual code and the command line
interface into two files and only include the first one.

>
> julia > include("test01.jl")   , where do I include the 2048 argument?

You can modify the ARGS array like any other imported global variable.

>
> Now I could do it form inside  julia but then I have no access to the
> variables.
>
> Sorry if this has been asked before but a search in google yielded no
> answers
>
> Cheers
> Gino

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

[Stefan Karpinski]

On Sun, Apr 3, 2016 at 8:50 AM, Scott Jones 
wrote:

> Yes, Python3 did switch from 1/2 returning a float, but Python3 still is
> having major problems with acceptance from the Python community, so I don't
> think that's the best example to use.
>

The change of division is not the reason people are not using Python 3.

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

[Scott Jones]

Yes, Python3 did switch from 1/2 returning a float, but Python3 still is 
having major problems with acceptance from the Python community, so I don't 
think that's the best example to use. It is a bit of a mess when you look 
at a number of languages.

Python2 Python3 Lua Julia CC++ CacheObjectScript
I*I I I I I I D
I/I I F F F I D
I//I I I I R - -
I\divI - - - I - -

where: I = Integer, F = Binary Float, D = Decimal Float, R = Rational, - = 
syntax error



On Sunday, April 3, 2016 at 8:01:07 AM UTC-4, Stefan Karpinski wrote:

> Python 3 changed the meaning of 1/2 to be 0.5, so arguing from a Pythonic 
> perspective would seem to indicate that Julia has avoided Python's original 
> mistake for / and chosen a behavior that Guido van Rossum and the the 
> Python community at large consider to be sufficiently much better to 
> warrant a rather long and annoying deprecation process. Also note that C 
> and Python are inconsistent in what / means: in C it does truncated 
> division while in Python it does floored division. Neither choice is 
> obviously entirely better, which is itself a problem: so you want / to be 
> integer division? Which one?
>
> On Sat, Apr 2, 2016 at 4:18 PM, Matt Bauman  > wrote:
>
>> I don't want to get too deep into the weeds here, but I want to point out 
>> some things I like about Julia's closed ranges:
>>
>> * Julia's ranges are just vectors of indices.  In exchange for giving up 
>> Python's offset style slicing, you get a fully-functional mathematical 
>> vector that supports all sorts of arithmetic. Idioms like `(-1:1)+i` allow 
>> you to very easily slide a 3-element window along your array.
>>
>> * Since they represent a collection of indices instead of elements 
>> between two fenceposts, Julia's ranges will throw bounds errors if the 
>> endpoints go beyond the end of the array.  I find these sorts of errors 
>> extremely valuable — if I'm indexing with a N-element range I want N 
>> elements back.
>>
>> * The only thing that's special about indexing by ranges is that they 
>> compute their elements on-the-fly and very efficiently.  You can create 
>> your own range-like array type very easily, and it can even generalize to 
>> multiple dimensions quite nicely.
>>
>> * Being vectors themselves, you can index into range objects.  In fact, 
>> they will smartly re-compute new ranges upon indexing (if they can).
>>
>> * In exchange for Python's negative indexing, you get the `end` keyword. 
>> It can be used directly in all sorts of computations.  In fact, you could 
>> use it in your example, replacing the hard-coded 100 with `end`. Now it 
>> supports arrays of all lengths. Circular buffers can be expressed as 
>> `buf[mod1(i, 
>> end)]`.
>>
>> Of course there are trade-offs to either approach, and it takes time to 
>> adjust when moving from one system to the other.
>>
>> If you work a lot with images and other higher-dimensional arrays, I 
>> recommend taking a look at Julia's multidimensional algorithms. I think 
>> Julia has a lot to offer in this domain and is quite unique in its 
>> multidimensional support. http://julialang.org/blog/2016/02/iteration
>>
>>
>> On Saturday, April 2, 2016 at 7:55:55 AM UTC-4, Spiritus Pap wrote:
>>>
>>> Hi there,
>>>
>>> TL;DR: A lot of people that could use julia (researchers currently using 
>>> python) won't. I give an example of how it makes my life hard, and I try to 
>>> suggest solutions.
>>>
>>> Iv'e been introduced to julia about a month ago.
>>> I'm an algorithmic researcher, I write mostly research code: statistics, 
>>> image processing, algorithms, etc.
>>> I use mostly python with numpy for my stuff, and C/++ when I need 
>>> performance.
>>> I was really happy when I heard of julia, because it takes the 
>>> simplicity of python and combines it with JIT compilation for speed!
>>>
>>> I REALLY tried to use julia, I really did. I tried to convince my 
>>> friends at work to use it too.
>>> However, there are a few things that make it unusable the way it is.
>>>
>>> Decisions that in my opinion were made by people who do not write 
>>> research-code:
>>> 1. Indexing in Julia. being 1 based and inclusive, instead of 0 based 
>>> and not including the end (like in c/python/lots of other stuff)
>>> 2. No simple integer-division operator.
>>>
>>> A simple example why it makes my *life hard*: Assume there is an array 
>>> of size 100, and i want to take the i_th portion of it out of n. This is a 
>>> common scenario for research-code, at least for me and my friends.
>>> In python:
>>> a[i*100/n:(i+1)*100/n]
>>> In julia:
>>> a[1+div(i*100,n):div((i+1)*100,n)]
>>>
>>> A lot more cumbersome in julia, and it is annoying and unattractive. 
>>> This is just a simple example.
>>>
>>> *Possible solutions:*
>>> The reason I'm writing this post is because I want to use julia, and I 
>>> want to to become great.
>>> *About the division:* I would suggest 

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

[Scott Jones]

For some reason, my posts are getting sent prematurely!  Continuing:

Since the integer division operator // of Python (2&3) and Lua already 
means something important in Julia, and \ is also taken, I'd like to 
propose \\ as an integer division operator for Julia.
Having to always type \ d i v  in the REPL, and something different in 
Emacs, or write things out as `div(a, b)` (6 characters typed!), is rather 
annoying, \\ is just a syntax error currently in Julia
and could easily be added to the parser and made a synonym to div (÷).

[julia-users] How to pass ARGS to a script inside julia

[Gino Serpa]

Hi,
I know that I can pass arguments to a script using ARGS and then just 
running from the console  prompt  as in

> julia test01.jl 2048
 
where the argument 2048 is passed to test01.jl. But what if I want to pass 
this argument inside julia to the same script

julia > include("test01.jl")   , where do I include the 2048 argument?

Now I could do it form inside  julia but then I have no access to the 
variables.

Sorry if this has been asked before but a search in google yielded no 
answers

Cheers
Gino 

Re: [julia-users] Re: Large number of methods for a function and Julia for data acquisition

[Stefan Karpinski]

I'm afraid that changing the subject here removes all context for this
message in most email systems. Groups seems to keep the message in context:

https://groups.google.com/d/msg/julia-users/Dt6nbfhtaNQ/TCy6zT9HAAAJ

On Sun, Apr 3, 2016 at 4:34 AM, Oliver Schulz 
wrote:

> Hi Andrew,
>
> On Saturday, April 2, 2016 at 7:10:00 PM UTC+2, Andrew Keller wrote:
>>
>> Regarding your first question posed in this thread, I think you might be
>> interested in this documentation
>>  of how
>> functions will work in Julia 0.5 if you haven't read it already.
>>
>
> Yes, I'm aware that some big changes are coming with 0.5, and many of them
> (e.g. threads and fast anonymous functions) are of course highly relevant
> to this kind of application. For now I'm kinda stuck with 0.4 for actual
> use cases, because so many packages (e.g. PyPlot, Gadfly, ...) have trouble
> with 0.5 at the moment. But once 0.5 is ready, I will probably not even try
> to keep things compatible with 0.4, as this is a new project anyway.
>
>
> I hope you don't mind that I've tried out your setindex and getindex
>> approach. [...] It is very pleasant to use but I have not benchmarked it in
>> any serious way [...] If you'd like me to try out something I'll see what I
>> can do.
>>
>
> Thanks, you're more than welcome! The more the merrier, and this can only
> profit from wide testing. It would be good to try how this performs with,
> say, about 500 feature types and 500 device types, each implementing like
> 100 features. I hope this will still perform well in dynamic dispatch
> situations - maybe one of the Julia experts can weigh in here?
>
>
> It sounds like you have probably been thinking deeply about instrument
>> control for a much longer period of time than I have.
>>
>
> Well, thinking and learning a lot from my earlier mistakes. :-)
>
>
> You can find any number of discussion threads, GitHub issues, etc. on
>> traits in Julia but I don't know what current consensus is.
>>
>
> I did play with some of the current approaches to traits in Julia a while
> ago (Mauro's and Tim's work), and it's definitely something to watch (I'd
> love to see something like that in Base some day). For now, I hope we may
> be able to get by without explicit "device classes".
>
>
>
>> Thanks for linking to your code. I have no experience with Scala but I
>> will take a look at it.
>>
>
> Don't judge to harshly. :-) This has been a work in progress for many
> years, and it is in active use for two long-term physics experiments and
> multiple lab applications - but since it was always driven by our current
> needs, I often didn't find time to port new ideas and concepts to older
> portions of the code. One of the goals was always to use it for both
> high-rate physics DAQ, and low-rate "slow-control"/SCADA applications. I
> was planning a major overhaul, but recently decided that Julia will be a
> better platform in the long run for various reasons (one of them that most
> students don't have time to learn several programming languages, and Scala
> isn't really an option for our kind of data analysis).
>
> Implementing specific devices has actually only been a fraction of the
> work - a large part has always been implementing communication protocols.
> For various devices, I needed (and implemented) VXI11, Modbus, SNMP, VME
> (over ethernet bridge), CANOpen (for one speficic gateway), and various
> vendor specific ASCII and binary protocols (e.g. Pfeiffer vaccum, old
> Keithley ASCII, etc.). Plus things like an SCPI parser, etc.. I look
> forward to port all of that to Julia - well, eventually ... ;-)
>
> I'd like the core to stay pure-Julia, though this will be challenging with
> VXI11 and SNMP, as there's no native-Julia ONC-RPC or SNMP library. And for
> devices that really need a vendor-specific VISA driver (because SCPI over
> VXI11 is not enough) Instruments.jl (
> https://github.com/BBN-Q/Instruments.jl) may come in play (haven't tried
> it yet).
>
> I'd love to work with other people interested in this - Julia is great at
> making data analysis fast and easy, not reason it shouldn't be as great at
> taking the data in the first place!
>
>
>
>> Unitful.jl and SIUnits.jl globally have the same approach [...] My
>> package only supports Julia 0.5 though. [...]An open question is how one
>> could dispatch on the dimensions (e.g. x::Length).
>>
>
> Ah, right, now I remember - i kinda mixed up SIUnits and Unitful, sorry. I
> did give Unitful a quick try when you announced it on the list, and I was
> very impressed. But then I kinda had to force myself to put it aside for a
> while, since I can't really switch to 0.5 yet. ;-) I do recall the
> discussion about dispatching on units, though - that would be way cool, but
> even without, Unitful will be a great ingredient to any Julia data
> acquisition solution.
>
>
> Cheers,
>
> Oliver
>
>

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

[Stefan Karpinski]

Python 3 changed the meaning of 1/2 to be 0.5, so arguing from a Pythonic
perspective would seem to indicate that Julia has avoided Python's original
mistake for / and chosen a behavior that Guido van Rossum and the the
Python community at large consider to be sufficiently much better to
warrant a rather long and annoying deprecation process. Also note that C
and Python are inconsistent in what / means: in C it does truncated
division while in Python it does floored division. Neither choice is
obviously entirely better, which is itself a problem: so you want / to be
integer division? Which one?

On Sat, Apr 2, 2016 at 4:18 PM, Matt Bauman  wrote:

> I don't want to get too deep into the weeds here, but I want to point out
> some things I like about Julia's closed ranges:
>
> * Julia's ranges are just vectors of indices.  In exchange for giving up
> Python's offset style slicing, you get a fully-functional mathematical
> vector that supports all sorts of arithmetic. Idioms like `(-1:1)+i` allow
> you to very easily slide a 3-element window along your array.
>
> * Since they represent a collection of indices instead of elements between
> two fenceposts, Julia's ranges will throw bounds errors if the endpoints go
> beyond the end of the array.  I find these sorts of errors extremely
> valuable — if I'm indexing with a N-element range I want N elements back.
>
> * The only thing that's special about indexing by ranges is that they
> compute their elements on-the-fly and very efficiently.  You can create
> your own range-like array type very easily, and it can even generalize to
> multiple dimensions quite nicely.
>
> * Being vectors themselves, you can index into range objects.  In fact,
> they will smartly re-compute new ranges upon indexing (if they can).
>
> * In exchange for Python's negative indexing, you get the `end` keyword.
> It can be used directly in all sorts of computations.  In fact, you could
> use it in your example, replacing the hard-coded 100 with `end`. Now it
> supports arrays of all lengths. Circular buffers can be expressed as 
> `buf[mod1(i,
> end)]`.
>
> Of course there are trade-offs to either approach, and it takes time to
> adjust when moving from one system to the other.
>
> If you work a lot with images and other higher-dimensional arrays, I
> recommend taking a look at Julia's multidimensional algorithms. I think
> Julia has a lot to offer in this domain and is quite unique in its
> multidimensional support. http://julialang.org/blog/2016/02/iteration
>
>
> On Saturday, April 2, 2016 at 7:55:55 AM UTC-4, Spiritus Pap wrote:
>>
>> Hi there,
>>
>> TL;DR: A lot of people that could use julia (researchers currently using
>> python) won't. I give an example of how it makes my life hard, and I try to
>> suggest solutions.
>>
>> Iv'e been introduced to julia about a month ago.
>> I'm an algorithmic researcher, I write mostly research code: statistics,
>> image processing, algorithms, etc.
>> I use mostly python with numpy for my stuff, and C/++ when I need
>> performance.
>> I was really happy when I heard of julia, because it takes the simplicity
>> of python and combines it with JIT compilation for speed!
>>
>> I REALLY tried to use julia, I really did. I tried to convince my friends
>> at work to use it too.
>> However, there are a few things that make it unusable the way it is.
>>
>> Decisions that in my opinion were made by people who do not write
>> research-code:
>> 1. Indexing in Julia. being 1 based and inclusive, instead of 0 based and
>> not including the end (like in c/python/lots of other stuff)
>> 2. No simple integer-division operator.
>>
>> A simple example why it makes my *life hard*: Assume there is an array
>> of size 100, and i want to take the i_th portion of it out of n. This is a
>> common scenario for research-code, at least for me and my friends.
>> In python:
>> a[i*100/n:(i+1)*100/n]
>> In julia:
>> a[1+div(i*100,n):div((i+1)*100,n)]
>>
>> A lot more cumbersome in julia, and it is annoying and unattractive. This
>> is just a simple example.
>>
>> *Possible solutions:*
>> The reason I'm writing this post is because I want to use julia, and I
>> want to to become great.
>> *About the division:* I would suggest *adding *an integer division
>> *operator*, such as *//*. Would help a lot. Yes, I think it should be by
>> default, so that newcomers would need the least amount of effort to use
>> julia comfortably.
>>
>> *About the indexing:* I realize that this is a decision made a long time
>> ago, and everything is built this way. Yes, it is like matlab, and no, it
>> is not a good thing.
>> I am a mathematician, and I almost always index my sequences expressions
>> in 0, it usually just makes more sense.
>> The problem is both in array (e.g. a[0]) and in slice (e.g. 0:10).
>> An array could be solved perhaps by a *custom *0 based *array object*.
>> But the slice? Maybe adding a 0 based *slice operator*(such as .. or _)?
>> is it possible to do 

Re: [julia-users] List comprehension for 1 <= i < j <= 4

[Tamas Papp]

vcat([[(i,j) for j in (1+i):4] for i in 1:4]...)

On Sun, Apr 03 2016, Jonatan Pallesen wrote:

> I want to make a list comprehension for 1 <= i < j <= 4. It can be done 
> with a for loop like this:
>
> l = []
> for i in 1:4, j in i+1:4
> push!(l, (i,j))
> end
>
> In python a list comprehension can be made like this
>
> l = [(i, j) for i in range(1, 5) for j in range(i+1, 5)]
>
> But this Julia code gives an error, saying i is not defined:
>
> l = [(i,j) for i in 1:4, j in i+1:4]
>
> Is there another approach? I feel like 4 lines to do this is excessive

[julia-users] List comprehension for 1 <= i < j <= 4

[Jonatan Pallesen]

I want to make a list comprehension for 1 <= i < j <= 4. It can be done 
with a for loop like this:

l = []
for i in 1:4, j in i+1:4
push!(l, (i,j))
end

In python a list comprehension can be made like this

l = [(i, j) for i in range(1, 5) for j in range(i+1, 5)]

But this Julia code gives an error, saying i is not defined:

l = [(i,j) for i in 1:4, j in i+1:4]

Is there another approach? I feel like 4 lines to do this is excessive

Re: [julia-users] how to compute result type of /

[Milan Bouchet-Valat]

Le dimanche 03 avril 2016 à 10:34 +0200, Tamas Papp a écrit :
> Hi,
> 
> I want to explicitly specify the type of a comprehension (cf #7258). If
> I have two values a::T and b::S, how can I compute the type of a/b using
> just T and S?
> 
> Currently I am using
> 
> typeof(one(T)/one(S))
> 
> but surely there is something more elegant (also, it would be nice to
> know in general, not just for arithmetic).
Unfortunately, I don't think there's a shorter solution.

The unexported promote_op() function could be used, but it's not
shorter (maybe it's more natural/explicit though):

julia> Base.promote_op(/, Int, Int)
Float64


For comprehensions, the long-term solution is clearly to get inference
do this automatically for you.


My two cents

> Best,
> 
> Tamas

[julia-users] Re: check exit code from ccall

[Andreas Lobinger]

ccall provides as output the return value of a call. If your library calls 
exit(1) then it interacts with the OS and asks for process termination.

On Sunday, April 3, 2016 at 9:52:08 AM UTC+2, Martin Kuzma wrote:
>
>
>
> Hi,
> is there a way to check exit status code from call to ccall? The c library 
> may call exit(1) if there is an error in the input and I want to be able to 
> check if exit code from ccall is 1. Thanks Martin
>

[julia-users] how to compute result type of /

[Tamas Papp]

Hi,

I want to explicitly specify the type of a comprehension (cf #7258). If
I have two values a::T and b::S, how can I compute the type of a/b using
just T and S?

Currently I am using

typeof(one(T)/one(S))

but surely there is something more elegant (also, it would be nice to
know in general, not just for arithmetic).

Best,

Tamas

[julia-users] Re: Large number of methods for a function and Julia for data acquisition

[Oliver Schulz]

Hi Andrew,

On Saturday, April 2, 2016 at 7:10:00 PM UTC+2, Andrew Keller wrote:
>
> Regarding your first question posed in this thread, I think you might be 
> interested in this documentation 
>  of how functions 
> will work in Julia 0.5 if you haven't read it already.
>

Yes, I'm aware that some big changes are coming with 0.5, and many of them 
(e.g. threads and fast anonymous functions) are of course highly relevant 
to this kind of application. For now I'm kinda stuck with 0.4 for actual 
use cases, because so many packages (e.g. PyPlot, Gadfly, ...) have trouble 
with 0.5 at the moment. But once 0.5 is ready, I will probably not even try 
to keep things compatible with 0.4, as this is a new project anyway.
 

I hope you don't mind that I've tried out your setindex and getindex 
> approach. [...] It is very pleasant to use but I have not benchmarked it in 
> any serious way [...] If you'd like me to try out something I'll see what I 
> can do.
>

Thanks, you're more than welcome! The more the merrier, and this can only 
profit from wide testing. It would be good to try how this performs with, 
say, about 500 feature types and 500 device types, each implementing like 
100 features. I hope this will still perform well in dynamic dispatch 
situations - maybe one of the Julia experts can weigh in here?
 

It sounds like you have probably been thinking deeply about instrument 
> control for a much longer period of time than I have.
>

Well, thinking and learning a lot from my earlier mistakes. :-)
 

You can find any number of discussion threads, GitHub issues, etc. on 
> traits in Julia but I don't know what current consensus is.
>

I did play with some of the current approaches to traits in Julia a while 
ago (Mauro's and Tim's work), and it's definitely something to watch (I'd 
love to see something like that in Base some day). For now, I hope we may 
be able to get by without explicit "device classes".

 

> Thanks for linking to your code. I have no experience with Scala but I 
> will take a look at it.
>

Don't judge to harshly. :-) This has been a work in progress for many 
years, and it is in active use for two long-term physics experiments and 
multiple lab applications - but since it was always driven by our current 
needs, I often didn't find time to port new ideas and concepts to older 
portions of the code. One of the goals was always to use it for both 
high-rate physics DAQ, and low-rate "slow-control"/SCADA applications. I 
was planning a major overhaul, but recently decided that Julia will be a 
better platform in the long run for various reasons (one of them that most 
students don't have time to learn several programming languages, and Scala 
isn't really an option for our kind of data analysis).

Implementing specific devices has actually only been a fraction of the work 
- a large part has always been implementing communication protocols. For 
various devices, I needed (and implemented) VXI11, Modbus, SNMP, VME (over 
ethernet bridge), CANOpen (for one speficic gateway), and various vendor 
specific ASCII and binary protocols (e.g. Pfeiffer vaccum, old Keithley 
ASCII, etc.). Plus things like an SCPI parser, etc.. I look forward to port 
all of that to Julia - well, eventually ... ;-)

I'd like the core to stay pure-Julia, though this will be challenging with 
VXI11 and SNMP, as there's no native-Julia ONC-RPC or SNMP library. And for 
devices that really need a vendor-specific VISA driver (because SCPI over 
VXI11 is not enough) Instruments.jl 
(https://github.com/BBN-Q/Instruments.jl) may come in play (haven't tried 
it yet).

I'd love to work with other people interested in this - Julia is great at 
making data analysis fast and easy, not reason it shouldn't be as great at 
taking the data in the first place!
 
  

> Unitful.jl and SIUnits.jl globally have the same approach [...] My package 
> only supports Julia 0.5 though. [...]An open question is how one could 
> dispatch on the dimensions (e.g. x::Length).
>

Ah, right, now I remember - i kinda mixed up SIUnits and Unitful, sorry. I 
did give Unitful a quick try when you announced it on the list, and I was 
very impressed. But then I kinda had to force myself to put it aside for a 
while, since I can't really switch to 0.5 yet. ;-) I do recall the 
discussion about dispatching on units, though - that would be way cool, but 
even without, Unitful will be a great ingredient to any Julia data 
acquisition solution.


Cheers,

Oliver

[julia-users] check exit code from ccall

[Martin Kuzma]

Hi,
is there a way to check exit status code from call to ccall? The c library 
may call exit(1) if there is an error in the input and I want to be able to 
check if exit code from ccall is 1. Thanks Martin