[julia-users] [ANN] Bay Area Julia Users meetup - Thursday, 16 January 2014

[Stu Thompson]

Hi folks,

The next meetupof 
the Bay Area Julia Users is set for 6:30pm Thursday, 16 January 2014 at Forio 
HQ
. 

Westley Hennigh will start with an introduction to 
Lumberjack.jl, 
a logging library for Julia.  Next up will be Jason Merrill will present 
his work on Truncated Power Series 
(PowerSeries.jl) 
which exports a Series type that represents a truncated power series by its 
coefficients. You can do arithmetic on Series and apply functions to series 
just as you would Real or Complex numbers.  There will be pizza, soft 
drinks and beer too.

Please let me know if you have any questions.  If you do plan on attending, 
it would be appreciated if you would sign up with the meetup.com system, 
although this not required.

We continue to search for people interested in presenting at future 
meetups.  Please drop me an email or find me at a future meetup if you are 
interested.

Happy New Year!

Stu

Re: [julia-users] Re: best way to do a.'*b, i.e., dot() without conjugating first argument

[Sheehan Olver]

My main problem is that

(a.'*b)[1,1]

looks a bit ugly.  I'll just implement my own dotu

Sent from my iPhone

> On Jan 3, 2014, at 12:21 AM, Stefan Karpinski  
> wrote:
> 
> Unless the vectors in question are small, the allocation of a one-element 
> array is unlikely to be significant. If the vectors are small, writing out 
> the dot product yourself is likely to be faster; In fact, it may be faster 
> anyway.
> 
>> On Jan 2, 2014, at 7:38 AM, Ivar Nesje  wrote:
>> 
>> Thanks for correcting me. I should have checked better before answering, 
>> especially because it is so simple in Julia to follow the functions and see 
>> what actually gets calculated.
>> 
>> kl. 13:29:49 UTC+1 torsdag 2. januar 2014 skrev Andreas Noack Jensen 
>> følgende:
>>> 
>>> The problem here is that the method in operators.jl is 
>>> At_mul_B(a,b)=transport(a)*b and therefore there is a transposed copy in 
>>> the calculation.
>>> 
>>> 
>>> 2014/1/2 Ivar Nesje 
 Julia does part of transformation automatically for you.
 
 If you look at
 
 julia> @which a.'*b
 At_mul_B(a,b) at operators.jl:122
 
 You can see that the call is automatically rewritten to At_mul_B(a,b) 
 without making a transposed copy.
 
 I am not sure what you can do about the result being a 1 element 
 Array{Complex{Float64},1} instead of just a Complex{Float64}.
 
 Ivar
 
 kl. 13:02:39 UTC+1 torsdag 2. januar 2014 skrev Sheehan Olver følgende:
> 
> I want to do
> 
>   a.'*b
> 
> where a and b are Vector{Complex}, but this returns an Array, not a 
> constant, and probably does unneccesary memory allocation for when 
> constructing  a.'
> 
> If it was 
> 
>   a'*b 
> 
> I can just replace it with dot(a,b).  Is there an equivalent that doesn't 
> conjugate the first argument?
>>> 
>>> 
>>> 
>>> -- 
>>> Med venlig hilsen
>>> 
>>> Andreas Noack Jensen

[julia-users] ERROR: invalid base 10 digit '.' in "0.5"

[Alfred Tarski]

Does anyone have an idea what is at fault? Is it PyPlot or julia? 

$ julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type "help()" to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-prerelease+804 (2014-01-02 21:40 UTC)
_/ |\__'_|_|_|\__'_| | Commit c2109c3 (0 days old master)
|__/ | x86_64-linux-gnu

julia> using PyPlot
ERROR: invalid base 10 digit '.' in "0.5"
in reload_path at loading.jl:146
in _require at loading.jl:59
in require at loading.jl:46
in reload_path at loading.jl:146
in _require at loading.jl:59
in require at loading.jl:43
while loading /home/aa/.julia/Color/src/Color.jl, in expression starting on 
line 192
while loading /home/aa/.julia/PyPlot/src/colormaps.jl, in expression 
starting on line 4
while loading /home/aa/.julia/PyPlot/src/PyPlot.jl, in expression starting 
on line 244

julia> 

[julia-users] problems with todays (nightly ...) julia

[Kjetil brinchmann Halvorsen]

I am running todays development version from within emacs with ess.
Look at the following:

julia> x = [1.,  2,  3,  4,  5]
5-element Array{Float64,1}:
Evaluation succeeded, but an error occurred while showing value of
type Array{Float64,1}:
ERROR: BoundsError()
 in parseint_nocheck at string.jl:1472
 in parseint_nocheck at string.jl:1509
 in parseint at string.jl:1512
 in writemime at repl.jl:21
 in display at multimedia.jl:117
 in display at multimedia.jl:119
 in display at multimedia.jl:151

What is this?

Kjetil

Re: [julia-users] Declaring types that are special cases of already existing composite types

[John Myles White]

Right now, there is no mechanism for doing the delegation I described earlier 
beyond simple macros like those I wrote up a long time ago.

For your use case, you would really want a method that wraps a given type in a 
new immutable type and then delegates all methods to the contained type unless 
they are explicitly overriden. Currently, that's not possible without a lot of 
legwork.

Since it seems like you mostly want to guarantee invariant properties of your 
data, you can just write functions that don't break those invariants when 
operating a standard DataFrame and then call them. The compiler won't give you 
provable guarantees that those invariants are never broken, but your code still 
will respect them. If the compiler gets new abilities, you could then easily 
upgrade your methods to refer to a new type that imposes the desired invariants.

 -- John

On Jan 2, 2014, at 2:00 PM, Christian Groll  
wrote:

> Recapturing, it hence seems like julia does not support this feature - 
> although I must admit that I did not get all the details in the answers ;-) 
> 
> Still, however, I would like to find some reasonable workaround to this 
> problem. In my opinion, the dataframe type should probably really cover 
> almost all cases of data storage in statistics / data analysis. Nevertheless, 
> I would very much like to be able to allow for some distinction between 
> different datasets. Hence, ideally I would like to have a type that behaves 
> almost exactly like a dataframe, while I am still able to overload certain 
> methods. For example, if I know that my dataset contains time series data, a 
> visualization plot(df::dataframe) should look different than a visualization 
> for geographic data on a map. Also, different datasets come with different 
> constraints: portfolio weights must sum to 1, correlations must be between -1 
> and 1, and so forth. Isn't there any way to reasonably implement this without 
> each time starting a new type from scratch?
> 
> I was only calling it subtype because I somewhere stumbled upon the advice 
> that it could work with subtyping the AbstractDataFrame type, but I didn't 
> get this running. Any tips on whether / how this would work?
> 
> Alternatively, I also found somewhere else a code snippet of John Myles White 
> about a redirect or delegate macro:
> macro redirect(t, comp, fname) 
> t = esc(t) 
> comp = esc(comp) 
> fname = esc(fname) 
> quote 
> ($fname)(a::($t), args...) = ($fname)(a.($comp), args...) 
> end 
> end 
> 
> This at least could be a starting point to give a new type the behavior of a 
> dataframe. Is there any update on this macro?
> 
> At last, I still do not get the memory problem with subtyping composite types 
> for my exact case. The subtypes that I would like to have do NOT have any 
> additional fields compared to their parent. They only shall help to allow 
> function dispatch and implementation of some constraints. A Portfolio type 
> still is nothing else than a dataframe, only that its values sum up to one. 
> You definitely need not further explain the memory issues here to me, because 
> I most likely do not understand them anyways. But are you really sure that 
> such a Portfolio type would have different memory requirements than a 
> dataframe? In effect, it should be nothing different, but only one special 
> case of all possible dataframes.
> 
> On Thursday, 2 January 2014 16:53:18 UTC+1, Stefan Karpinski wrote:
> On Thu, Jan 2, 2014 at 10:01 AM, Mauro  wrote:
> Only abstract types can be subtyped (and if I recall correctly this is going 
> to stay that way for some type-theory-reason).
> 
> It's not for a type theory reason – if anything, it's the opposite of a type 
> theory reason. If Float64 can be subtyped, then then an Array{Float64} can 
> hold objects of arbitrary size. Thus, you can't represent it as inline data, 
> but rather have to store the array as pointers to boxed, heap-allocated 
> values. Not only is this horribly inefficient (200% storage overhead on 
> 64-bit machines), but it completely destroys interoperability with BLAS, 
> FFTW, etc.
> 
> Some o.o. languages have allowed declaring types to be "final" as a way of 
> dealing with this issue (you also need immutability and/or value types to 
> fully solve the array storage problem). After a few decades of real-world 
> o.o. programming, however, the best practice that's emerged is that you 
> should only subtype intentional supertypes – types that are very carefully 
> designed to be subtypeable. Where a classically o.o. language might do Ac :> 
> Bc, where Ac and Bc are both concrete and Ac is a supertype of Bc, in Julia 
> you would have Aj' :> Aj, Bj where the abstract aspect of Ac is distilled 
> into the purely abstract type, Aj', while the concrete aspect of Ac is 
> implemented by Aj, which is a sibling of Bj instead of its parent. I've found 
> that while this requires a slight shift in think

Re: [julia-users] Declaring types that are special cases of already existing composite types

[Christian Groll]

Recapturing, it hence seems like julia does not support this feature - 
although I must admit that I did not get all the details in the answers ;-) 

Still, however, I would like to find some reasonable workaround to this 
problem. In my opinion, the dataframe type should probably really cover 
almost all cases of data storage in statistics / data analysis. 
Nevertheless, I would very much like to be able to allow for some 
distinction between different datasets. Hence, ideally I would like to have 
a type that behaves almost exactly like a dataframe, while I am still able 
to overload certain methods. For example, if I know that my dataset 
contains time series data, a visualization plot(df::dataframe) should look 
different than a visualization for geographic data on a map. Also, 
different datasets come with different constraints: portfolio weights must 
sum to 1, correlations must be between -1 and 1, and so forth. Isn't there 
any way to reasonably implement this without each time starting a new type 
from scratch?

I was only calling it subtype because I somewhere stumbled upon the advice 
that it could work with subtyping the AbstractDataFrame type, but I didn't 
get this running. Any tips on whether / how this would work?

Alternatively, I also found somewhere else a code snippet of John Myles 
White about a redirect or delegate macro:
macro redirect(t, comp, fname) 
t = esc(t) 
comp = esc(comp) 
fname = esc(fname) 
quote 
($fname)(a::($t), args...) = ($fname)(a.($comp), args...) 
end 
end 

This at least could be a starting point to give a new type the behavior of 
a dataframe. Is there any update on this macro?

At last, I still do not get the memory problem with subtyping composite 
types for my exact case. The subtypes that I would like to have do NOT have 
any additional fields compared to their parent. They only shall help to 
allow function dispatch and implementation of some constraints. A Portfolio 
type still is nothing else than a dataframe, only that its values sum up to 
one. You definitely need not further explain the memory issues here to me, 
because I most likely do not understand them anyways. But are you really 
sure that such a Portfolio type would have different memory requirements 
than a dataframe? In effect, it should be nothing different, but only one 
special case of all possible dataframes.

On Thursday, 2 January 2014 16:53:18 UTC+1, Stefan Karpinski wrote:
>
> On Thu, Jan 2, 2014 at 10:01 AM, Mauro  >wrote:
>
>> Only abstract types can be subtyped (and if I recall correctly this 
>> is going to stay that way for some type-theory-reason).
>>
>
> It's not for a type theory reason – if anything, it's the opposite of a 
> type theory reason. If Float64 can be subtyped, then then an Array{Float64} 
> can hold objects of arbitrary size. Thus, you can't represent it as inline 
> data, but rather have to store the array as pointers to boxed, 
> heap-allocated values. Not only is this horribly inefficient (200% storage 
> overhead on 64-bit machines), but it completely destroys interoperability 
> with BLAS, FFTW, etc.
>
> Some o.o. languages have allowed declaring types to be "final" as a way of 
> dealing with this issue (you also need immutability and/or value types to 
> fully solve the array storage problem). After a few decades of real-world 
> o.o. programming, however, the best practice that's emerged is that you 
> should only subtype intentional supertypes – types that are very carefully 
> designed to be subtypeable. Where a classically o.o. language might do Ac 
> :> Bc, where Ac and Bc are both concrete and Ac is a supertype of Bc, in 
> Julia you would have Aj' :> Aj, Bj where the abstract aspect of Ac is 
> distilled into the purely abstract type, Aj', while the concrete aspect of 
> Ac is implemented by Aj, which is a sibling of Bj instead of its parent. 
> I've found that while this requires a slight shift in thinking, the 
> resulting designs tend to be much better: the abstract behavioral aspect of 
> Aj' is completely separated from any implementation concerns since you're 
> not allowed to mix them.
>
>

Re: [julia-users] Declaring types that are special cases of already existing composite types

[Stefan Karpinski]

On Thu, Jan 2, 2014 at 10:01 AM, Mauro  wrote:

> Only abstract types can be subtyped (and if I recall correctly this
> is going to stay that way for some type-theory-reason).
>

It's not for a type theory reason – if anything, it's the opposite of a
type theory reason. If Float64 can be subtyped, then then an Array{Float64}
can hold objects of arbitrary size. Thus, you can't represent it as inline
data, but rather have to store the array as pointers to boxed,
heap-allocated values. Not only is this horribly inefficient (200% storage
overhead on 64-bit machines), but it completely destroys interoperability
with BLAS, FFTW, etc.

Some o.o. languages have allowed declaring types to be "final" as a way of
dealing with this issue (you also need immutability and/or value types to
fully solve the array storage problem). After a few decades of real-world
o.o. programming, however, the best practice that's emerged is that you
should only subtype intentional supertypes – types that are very carefully
designed to be subtypeable. Where a classically o.o. language might do Ac
:> Bc, where Ac and Bc are both concrete and Ac is a supertype of Bc, in
Julia you would have Aj' :> Aj, Bj where the abstract aspect of Ac is
distilled into the purely abstract type, Aj', while the concrete aspect of
Ac is implemented by Aj, which is a sibling of Bj instead of its parent.
I've found that while this requires a slight shift in thinking, the
resulting designs tend to be much better: the abstract behavioral aspect of
Aj' is completely separated from any implementation concerns since you're
not allowed to mix them.

Re: [julia-users] Declaring types that are special cases of already existing composite types

[John Myles White]

Concrete types can't be subtyped because you need to know exactly how much 
memory space they occupy.

 -- John

On Jan 2, 2014, at 10:01 AM, Mauro  wrote:

> Only abstract types can be subtyped (and if I recall correctly this is
> going to stay that way for some type-theory-reason).
> 
> Further, at the moment abstract types cannot have fields, i.e. cannot be
> composite types.  However, this might change sometime, have a look at the
> issue:
> 
> https://github.com/JuliaLang/julia/issues/4935
> 
> (which is also referenced in the mailing list thread mentioned by tshort)
> 
> Now, all of this does not help with your quest, sorry, but it may be of
> some interest.
> 
> On Thu, 2014-01-02 at 16:23, Christian Groll wrote:
>> My interest lies in the implementation of types that are special cases of 
>> already existing composite types.
>> 
>> For example, I want to implement a type Portfolio, which is just a 
>> DataFrame with two additional requirements:
>> - all columns are of numeric type
>> - the sum of the entries in each row must be equal to 1
>> 
>> Or, I want to implement a type TimeSeries, which is just a DataFrame where 
>> the first column consists of dates. 
>> 
>> I think the way to go here would be to implement some type of constraint 
>> checking in the setindex! methods, although this would not prevent messing 
>> with the entries by way of directly setting the fields of the type. 
>> However, once there exist convenient getindex and setindex! methods, I hope 
>> that basically nobody would mess with the values directly, and complete 
>> immutability is not necessarily needed.
>> 
>> What I am trying to achieve is something that I think is called inheritance 
>> in other languages, where classes can simply be declared as subclasses to 
>> already existing classes. 
>> 
>> So the question is, whether something like this is possible in julia as 
>> well? As far as I get it, there is no way to declare a type to be a subtype 
>> of a composite type.
>> Or, if this is not possible, is there any way around, like for example 
>> declaring a type portfolio,
>> 
>> type Portfolio
>>   weights::DataVector{Float64}
>> end
>> 
>> where I can simply relate all setindex! methods to the respective methods 
>> of DataVector, adding constraint checks where necessary.
>> 
>> function Base.setindex!(pf::Portfolio,
>>v::Any,
>>col_ind::ColumnIndex)
>>if check_constraints(pf, v, col_ind)
>>   setindex!(pf.weights, v, col_ind)
>>else
>>   error("constraints not fulfilled.")
>>end
>> end
>> 
>> However, I then would need some type of metaprogramming such that I do not 
>> have to implement all the numerous setindex! methods of DataVector from 
>> scratch up.
> 

Re: [julia-users] Declaring types that are special cases of already existing composite types

[Mauro]

Only abstract types can be subtyped (and if I recall correctly this is
going to stay that way for some type-theory-reason).

Further, at the moment abstract types cannot have fields, i.e. cannot be
composite types.  However, this might change sometime, have a look at the
issue:

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

(which is also referenced in the mailing list thread mentioned by tshort)

Now, all of this does not help with your quest, sorry, but it may be of
some interest.

On Thu, 2014-01-02 at 16:23, Christian Groll wrote:
> My interest lies in the implementation of types that are special cases of 
> already existing composite types.
>
> For example, I want to implement a type Portfolio, which is just a 
> DataFrame with two additional requirements:
> - all columns are of numeric type
> - the sum of the entries in each row must be equal to 1
>
> Or, I want to implement a type TimeSeries, which is just a DataFrame where 
> the first column consists of dates. 
>
> I think the way to go here would be to implement some type of constraint 
> checking in the setindex! methods, although this would not prevent messing 
> with the entries by way of directly setting the fields of the type. 
> However, once there exist convenient getindex and setindex! methods, I hope 
> that basically nobody would mess with the values directly, and complete 
> immutability is not necessarily needed.
>
> What I am trying to achieve is something that I think is called inheritance 
> in other languages, where classes can simply be declared as subclasses to 
> already existing classes. 
>
> So the question is, whether something like this is possible in julia as 
> well? As far as I get it, there is no way to declare a type to be a subtype 
> of a composite type.
> Or, if this is not possible, is there any way around, like for example 
> declaring a type portfolio,
>
> type Portfolio
>weights::DataVector{Float64}
> end
>
> where I can simply relate all setindex! methods to the respective methods 
> of DataVector, adding constraint checks where necessary.
>
> function Base.setindex!(pf::Portfolio,
> v::Any,
> col_ind::ColumnIndex)
> if check_constraints(pf, v, col_ind)
>setindex!(pf.weights, v, col_ind)
> else
>error("constraints not fulfilled.")
> end
> end
>
> However, I then would need some type of metaprogramming such that I do not 
> have to implement all the numerous setindex! methods of DataVector from 
> scratch up.

Re: [julia-users] Declaring types that are special cases of already existing composite types

[Tom Short]

There are other mailing list threads on this. See here for one:

https://groups.google.com/d/msg/julia-users/yCjsY9g9_Lg/4oYlkf3DFHYJ

For your Portfolio use case, I'd be tempted to stick with DataFrames
and usage conventions. Maybe add a `checkportfolio` function to ensure
consistency. Another option is a thin wrapper type that includes an
AbstractDataFrame. If you don't want to write the getindex and
setindex! functions, then maybe just functions to convert between
Portfolios and AbstractDataFrames would be enough.



On Thu, Jan 2, 2014 at 9:23 AM, Christian Groll
 wrote:
> My interest lies in the implementation of types that are special cases of
> already existing composite types.
>
> For example, I want to implement a type Portfolio, which is just a DataFrame
> with two additional requirements:
> - all columns are of numeric type
> - the sum of the entries in each row must be equal to 1
>
> Or, I want to implement a type TimeSeries, which is just a DataFrame where
> the first column consists of dates.
>
> I think the way to go here would be to implement some type of constraint
> checking in the setindex! methods, although this would not prevent messing
> with the entries by way of directly setting the fields of the type. However,
> once there exist convenient getindex and setindex! methods, I hope that
> basically nobody would mess with the values directly, and complete
> immutability is not necessarily needed.
>
> What I am trying to achieve is something that I think is called inheritance
> in other languages, where classes can simply be declared as subclasses to
> already existing classes.
>
> So the question is, whether something like this is possible in julia as
> well? As far as I get it, there is no way to declare a type to be a subtype
> of a composite type.
> Or, if this is not possible, is there any way around, like for example
> declaring a type portfolio,
>
> type Portfolio
>weights::DataVector{Float64}
> end
>
> where I can simply relate all setindex! methods to the respective methods of
> DataVector, adding constraint checks where necessary.
>
> function Base.setindex!(pf::Portfolio,
> v::Any,
> col_ind::ColumnIndex)
> if check_constraints(pf, v, col_ind)
>setindex!(pf.weights, v, col_ind)
> else
>error("constraints not fulfilled.")
> end
> end
>
> However, I then would need some type of metaprogramming such that I do not
> have to implement all the numerous setindex! methods of DataVector from
> scratch up.

Re: [julia-users] create a type for points on n-dimensional simplex

[Tim Holy]

On Thursday, January 02, 2014 06:00:06 AM Christian Groll wrote:
> Hence,
> what I am searching for is probably a way to inherit all methods from
> Array{Float64}, only manipulating the setindex! methods, hopefully with
> some type of metaprogramming.

You should just be able to declare your type as a subtype of AbstractArray, 
and then override setindex! for your specific type.

--Tim

[julia-users] Declaring types that are special cases of already existing composite types

[Christian Groll]

My interest lies in the implementation of types that are special cases of 
already existing composite types.

For example, I want to implement a type Portfolio, which is just a 
DataFrame with two additional requirements:
- all columns are of numeric type
- the sum of the entries in each row must be equal to 1

Or, I want to implement a type TimeSeries, which is just a DataFrame where 
the first column consists of dates. 

I think the way to go here would be to implement some type of constraint 
checking in the setindex! methods, although this would not prevent messing 
with the entries by way of directly setting the fields of the type. 
However, once there exist convenient getindex and setindex! methods, I hope 
that basically nobody would mess with the values directly, and complete 
immutability is not necessarily needed.

What I am trying to achieve is something that I think is called inheritance 
in other languages, where classes can simply be declared as subclasses to 
already existing classes. 

So the question is, whether something like this is possible in julia as 
well? As far as I get it, there is no way to declare a type to be a subtype 
of a composite type.
Or, if this is not possible, is there any way around, like for example 
declaring a type portfolio,

type Portfolio
   weights::DataVector{Float64}
end

where I can simply relate all setindex! methods to the respective methods 
of DataVector, adding constraint checks where necessary.

function Base.setindex!(pf::Portfolio,
v::Any,
col_ind::ColumnIndex)
if check_constraints(pf, v, col_ind)
   setindex!(pf.weights, v, col_ind)
else
   error("constraints not fulfilled.")
end
end

However, I then would need some type of metaprogramming such that I do not 
have to implement all the numerous setindex! methods of DataVector from 
scratch up.

Re: [julia-users] create a type for points on n-dimensional simplex

[Christian Groll]

Thanks for the suggestions! I think I will go with Steven G. Johnson's 
solution and try to implement setindex! such as to be able to guarantee the 
simplex constraints. Once that convenient getindex and setindex! methods 
are implemented, I hope that nobody tries to mess with the fields directly. 
In the end, complete immutability is rather a subordinate goal in my case. 

However, I am still looking for a way to implement the constraints more 
conveniently than writing all possible setindex! methods from scratch up, 
especially since I ultimately would like my type to behave just identical 
to a standard Array{Float64} (besides the constraints, of course). Hence, 
what I am searching for is probably a way to inherit all methods from 
Array{Float64}, only manipulating the setindex! methods, hopefully with 
some type of metaprogramming. 

For this, I think it is better to start a new threat, since I suppose it 
should be a more general topic that probably more julia users could search 
for.

On Tuesday, 31 December 2013 16:07:57 UTC+1, Steven G. Johnson wrote:
>
>
>
> On Tuesday, December 31, 2013 7:13:10 AM UTC-5, Christian Groll wrote:
>>
>> However, I do not get how I could extend this for the n-dimensional case. 
>> Here, I thought that I would have to use one field which stores a 
>> n-dimensional vector:
>>
>> immutable nDimSimplex
>> points::Vector{Float64}
>> 
>> nDimSimplex(x::Vector{Float64}) = (abs(sum(x) - 1) > 1e-10) ? 
>> error("entries must sum to one") : new(x)
>> end
>>
>> Now, I think that it will not be possible to change the vector that the 
>> field points to. However, the entries of the vector itself still can be 
>> changed without restrictions. Any recommendations?
>>
>
> You could simply tell users not to access simplex.points directly.  
> Instead, override getindex/setindex! so that you can do simplex[i] for 
> simplex <: nDimSimplex.  Your setindex! method could enforce the invariants 
> (e.g. dividing by sum(x) after every change to renormalize, and throwing an 
> error for negative entries.)
>
> (I would also make nDimSimplex a subtype of AbstractVector{Float64}.  For 
> AbstractVector subtypes, you should normally provide methods for at least: 
> size, getindex, setindex!, and similar.)
>

Re: [julia-users] Style Guideline

[John Myles White]

Thanks everyone for the feedback. Going to try to synthesize responses this 
weekend. Been distracted by a major push to add more database support to Julia.

 — John

On Jan 2, 2014, at 6:02 AM, Keith Campbell  wrote:

> +1 for Eric's proposal for a 100 character line length.  The old 80 character 
> limit in PEP 8 was the one bit of that guideline I could never abide.
> 
> +1 also for Milan's proposal regarding brief comments describing a function's 
> purpose.  
> 
> And thank you John for pushing a standard that can enable tooling support.  
> 
> On Thursday, January 2, 2014 5:15:19 AM UTC-5, Marcus Urban wrote:
> Do people using Julia really like underscores that much? I find them 
> generally unsightly, and I do not plan to use them.

Re: [julia-users] Re: best way to do a.'*b, i.e., dot() without conjugating first argument

[Stefan Karpinski]

Unless the vectors in question are small, the allocation of a one-element array 
is unlikely to be significant. If the vectors are small, writing out the dot 
product yourself is likely to be faster; In fact, it may be faster anyway.

> On Jan 2, 2014, at 7:38 AM, Ivar Nesje  wrote:
> 
> Thanks for correcting me. I should have checked better before answering, 
> especially because it is so simple in Julia to follow the functions and see 
> what actually gets calculated.
> 
> kl. 13:29:49 UTC+1 torsdag 2. januar 2014 skrev Andreas Noack Jensen følgende:
>> 
>> The problem here is that the method in operators.jl is 
>> At_mul_B(a,b)=transport(a)*b and therefore there is a transposed copy in the 
>> calculation.
>> 
>> 
>> 2014/1/2 Ivar Nesje 
>>> Julia does part of transformation automatically for you.
>>> 
>>> If you look at
>>> 
>>> julia> @which a.'*b
>>> At_mul_B(a,b) at operators.jl:122
>>> 
>>> You can see that the call is automatically rewritten to At_mul_B(a,b) 
>>> without making a transposed copy.
>>> 
>>> I am not sure what you can do about the result being a 1 element 
>>> Array{Complex{Float64},1} instead of just a Complex{Float64}.
>>> 
>>> Ivar
>>> 
>>> kl. 13:02:39 UTC+1 torsdag 2. januar 2014 skrev Sheehan Olver følgende:
 
 I want to do
 
   a.'*b
 
 where a and b are Vector{Complex}, but this returns an Array, not a 
 constant, and probably does unneccesary memory allocation for when 
 constructing  a.'
 
 If it was 
 
   a'*b 
 
 I can just replace it with dot(a,b).  Is there an equivalent that doesn't 
 conjugate the first argument?
>> 
>> 
>> 
>> -- 
>> Med venlig hilsen
>> 
>> Andreas Noack Jensen

Re: [julia-users] Re: best way to do a.'*b, i.e., dot() without conjugating first argument

[Ivar Nesje]

Thanks for correcting me. I should have checked better before answering, 
especially because it is so simple in Julia to follow the functions and see 
what actually gets calculated.

kl. 13:29:49 UTC+1 torsdag 2. januar 2014 skrev Andreas Noack Jensen 
følgende:
>
> The problem here is that the method in operators.jl is 
> At_mul_B(a,b)=transport(a)*b and therefore there is a transposed copy in 
> the calculation.
>
>
> 2014/1/2 Ivar Nesje >
>
>> Julia does part of transformation automatically for you.
>>
>> If you look at
>>
>> julia> @which a.'*b
>> At_mul_B(a,b) at operators.jl:122
>>
>> You can see that the call is automatically rewritten to At_mul_B(a,b) 
>> without making a transposed copy.
>>
>> I am not sure what you can do about the result being a 1 element 
>> Array{Complex{Float64},1} instead of just a Complex{Float64}.
>>
>> Ivar
>>
>> kl. 13:02:39 UTC+1 torsdag 2. januar 2014 skrev Sheehan Olver følgende:
>>
>>>
>>> I want to do
>>>
>>>   a.'*b
>>>
>>> where a and b are Vector{Complex}, but this returns an Array, not a 
>>> constant, and probably does unneccesary memory allocation for when 
>>> constructing  a.'
>>>
>>> If it was 
>>>
>>>   a'*b 
>>>
>>> I can just replace it with dot(a,b).  Is there an equivalent that 
>>> doesn't conjugate the first argument?
>>>
>>
>
>
> -- 
> Med venlig hilsen
>
> Andreas Noack Jensen
>  

Re: [julia-users] Re: best way to do a.'*b, i.e., dot() without conjugating first argument

[Andreas Noack Jensen]

The problem here is that the method in operators.jl is
At_mul_B(a,b)=transport(a)*b and therefore there is a transposed copy in
the calculation.


2014/1/2 Ivar Nesje 

> Julia does part of transformation automatically for you.
>
> If you look at
>
> julia> @which a.'*b
> At_mul_B(a,b) at operators.jl:122
>
> You can see that the call is automatically rewritten to At_mul_B(a,b)
> without making a transposed copy.
>
> I am not sure what you can do about the result being a 1 element
> Array{Complex{Float64},1} instead of just a Complex{Float64}.
>
> Ivar
>
> kl. 13:02:39 UTC+1 torsdag 2. januar 2014 skrev Sheehan Olver følgende:
>
>>
>> I want to do
>>
>>   a.'*b
>>
>> where a and b are Vector{Complex}, but this returns an Array, not a
>> constant, and probably does unneccesary memory allocation for when
>> constructing  a.'
>>
>> If it was
>>
>>   a'*b
>>
>> I can just replace it with dot(a,b).  Is there an equivalent that doesn't
>> conjugate the first argument?
>>
>


-- 
Med venlig hilsen

Andreas Noack Jensen

[julia-users] Re: best way to do a.'*b, i.e., dot() without conjugating first argument

[Ivar Nesje]

Julia does part of transformation automatically for you.

If you look at

julia> @which a.'*b
At_mul_B(a,b) at operators.jl:122

You can see that the call is automatically rewritten to At_mul_B(a,b) 
without making a transposed copy.

I am not sure what you can do about the result being a 1 element 
Array{Complex{Float64},1} instead of just a Complex{Float64}.

Ivar

kl. 13:02:39 UTC+1 torsdag 2. januar 2014 skrev Sheehan Olver følgende:
>
>
> I want to do
>
>   a.'*b
>
> where a and b are Vector{Complex}, but this returns an Array, not a 
> constant, and probably does unneccesary memory allocation for when 
> constructing  a.'
>
> If it was 
>
>   a'*b 
>
> I can just replace it with dot(a,b).  Is there an equivalent that doesn't 
> conjugate the first argument?
>

Re: [julia-users] best way to do a.'*b, i.e., dot() without conjugating first argument

[Andreas Noack Jensen]

Right now there is no optimised build in function for that operation.
Julia's dot wraps BLAS' xdotc for complex arguments and xdotu (which is
what you want) is not wrapped at all.

Maybe it would be better if the BLAS wrappers have the same names as the
BLAS functions except for the data type letter, i.e. dot, dotu and dotc.


2014/1/2 Sheehan Olver 

>
> I want to do
>
>   a.'*b
>
> where a and b are Vector{Complex}, but this returns an Array, not a
> constant, and probably does unneccesary memory allocation for when
> constructing  a.'
>
> If it was
>
>   a'*b
>
> I can just replace it with dot(a,b).  Is there an equivalent that doesn't
> conjugate the first argument?
>



-- 
Med venlig hilsen

Andreas Noack Jensen

[julia-users] best way to do a.'*b, i.e., dot() without conjugating first argument

[Sheehan Olver]

I want to do

  a.'*b

where a and b are Vector{Complex}, but this returns an Array, not a 
constant, and probably does unneccesary memory allocation for when 
constructing  a.'

If it was 

  a'*b 

I can just replace it with dot(a,b).  Is there an equivalent that doesn't 
conjugate the first argument?

[julia-users] Re: Style Guideline

[Keith Campbell]

+1 for Eric's proposal for a 100 character line length.  The old 80 
character limit in PEP 8 was the one bit of that guideline I could never 
abide.

+1 also for Milan's proposal regarding brief comments describing a 
function's purpose.  

And thank you John for pushing a standard that can enable tooling support.  

On Thursday, January 2, 2014 5:15:19 AM UTC-5, Marcus Urban wrote:
>
> Do people using Julia really like underscores that much? I find them 
> generally unsightly, and I do not plan to use them.
>

[julia-users] Re: Style Guideline

[Marcus Urban]

Do people using Julia really like underscores that much? I find them 
generally unsightly, and I do not plan to use them.