[julia-users] most generic way to request iterable type as input

[Kevin Kunzmann]

Hi,

say I want to define a custom type with a field that accepts any kind of 
iterable integer type as valid input (both 1:3 as well as collect(1:3)), 
how would I do that in the most generic way? I know that I can use

type test{T<:integer}
 a::Union{Range{T},Vector{T}}
end

But there might be other iterable integer types that I did not think of 
during implementation - how can I make the code even more generic?

Best,

Kevin 

[julia-users] package reproducibility

[Kevin Kunzmann]

Hey,

I was just wondering whether Julia has a checkpoint-like functionality (R 
checkpoint-package 
) for using 
a specific checkpoint of the package ecosystem. With quick development 
happening this would improve reproducibility drastically.

Best,

Kevin 

Re: [julia-users] Re: Defining a new numeric type with minimal effort

[Kevin Kunzmann]

Taking your last example to the console, still I cannot add two 
"Probabilities" despite them being instances of a subtype of "Real". What I 
was looking for is the Julian way of thinking about inherited behaviour 
from numeric types. Now, I slowly wrap my mind around the idea that there s 
nothing to inherit...
But srsly, is there no way of making all functions that accept Reals also 
accept Probabilities? I can't reimplement them all, can I? Think of *(a,b), 
sin(a), /(a,b)

On Saturday, 11 June 2016 09:40:38 UTC+2, Jeffrey Sarnoff wrote:
>
> , as 'Real' is expecting it to be named 'val'? Jeez,
>
> No, Real is an abstract type that is closer to being a label sewn to the 
> root of a tree -- Real does not have any investment in how you name the 
> fields of your type.
>
> There is no way of telling which fileds are accessed how by all methods 
>> operating on that type x
>
> One scenario, you designed the type and determine the sorts of information 
> to be held as fields of the type.  You write specializations of generic 
> methods that pertain to using the type.  In that situation, your actively 
> maintained documentation knows and tells or you revisit your own source 
> code for that knowledge.  In any event, Julia is happy to help, providing 
> you with easily introduced method specific notes.   Another scenario, you 
> did the same thing and I want to use the type.  Well, I'd look at the 
> README.md file and if any, other docs.  Then, knowing the care you take 
> with programming, and seeing from a few simples examples you provide that 
> values of this Probability type are floating point representations of 
> independent likelihoods ...
> I would use the type without any desire to know which field(s) are read or 
> altered in the process of determining the probability than any one of my 
> five experts in origami will hand me a paper swan to drop from up here 
> before the building closes.
>
> the cleanest way to ensure that I pass a valid probability to my function 
>> (figure between 0 and 1)
>
> Do you want to raise an exception if a value is neither zero nor one nor 
> between zero and one?
> Do you want to clamp negative values to zero and clamp positive values 
> above one to one?
> Or do you want to clamp values that are within, say, -1//4096 .. 
> +4097//4096, and throw an exception outside of that range?
>
> (in this circumstance, for 'type' use 'immutable' and your typed values 
> will live and move in memory just like Float64 values. without interposed 
> indiirection.)
>
> immutable Probability
> val::Float64
>
> Probability(val::Float64) =  ( 0.0 <= val <= 1.0 ) ? new(val) : 
> throw(ErrorException("Probabilities must be within 0..1"))
> end
>
> (do you prefer the field name 'p' and to clamp the value?)
>
> immutable Probability
> p::Float64
>
> Probability(p::Float64) = new( max(0.0. min(p, 1.0)) )
> end
>
> Probability{T<:Real}(x::T) = Probability( convert(Float64, x) )
>
>  
>
>
> On Saturday, June 11, 2016 at 1:54:42 AM UTC-4, Kevin Kunzmann wrote:
>>
>> Hey,
>>
>> thanks for sticking with me ;)
>>
>> I am, however, a little bit confused now (seems that oo and parallelism 
>> are the hardest to grasp in julia).
>>
>> I see that '+' was a bad example. So my error was, that I did not name 
>> the field correctly, as 'Real' is expecting it to be named 'val'? Jeez, if 
>> this is true then how is one ever going to 'inherit correctly' from a 
>> complicated abstract type? There is no way of telling which fileds are 
>> accessed how by all methods operating on that type x)
>>
>> So, put simply: What is the Julia way of ensuring that I pass a valid 
>> probability to my function (figure between 0 and 1). Please do not tell me 
>> that I am supposed to use @assert statements x)
>> I would feel that a new type would be the cleanest way to do so?
>>
>> Best,
>>
>> Kevin 
>>
>> On Saturday, 11 June 2016 04:37:32 UTC+2, Jeffrey Sarnoff wrote:
>>>
>>> Hi Kevin,
>>>
>>> Right questions, different way.
>>>
>>> Julia's type system is
>>>of  shared behavior for sharing behaviors.
>>>for specialization as constructive delegation
>>>
>>> Real is an abstract type that is supertype to some other abstract types 
>>>(Integer, Rational, FloatingPoint, FixedPoint, Probability, ...).
>>> 
>>> 

Re: [julia-users] Re: Defining a new numeric type with minimal effort

[Kevin Kunzmann]

Okay,

so what I want to do is

immutable MyType{T<:Real}
  val::T
  function MyType(x::T)
@assert 0 <= x
@assert x <= 1
new(x)
  end
end
MyType{T<:Real}(x::T) = MyType{T}(x)

So how do I get this thing to "walk", i.e., get "*" functionality. Out of 
the box I would feel that a subtype of Real should "inherit" +-*/ in some 
way - whats the point of being a subtype of Real otherwise?

What I would hope for is that I only need to provide a convert method from 
Real back to MyType, so that the operation can be performed as for a 
suitable Real and then the conversion back ensures type consistency.

I feel as if I am still missing the central point here...

Best Kevin


On Saturday, 11 June 2016 07:54:42 UTC+2, Kevin Kunzmann wrote:
>
> Hey,
>
> thanks for sticking with me ;)
>
> I am, however, a little bit confused now (seems that oo and parallelism 
> are the hardest to grasp in julia).
>
> I see that '+' was a bad example. So my error was, that I did not name the 
> field correctly, as 'Real' is expecting it to be named 'val'? Jeez, if this 
> is true then how is one ever going to 'inherit correctly' from a 
> complicated abstract type? There is no way of telling which fileds are 
> accessed how by all methods operating on that type x)
>
> So, put simply: What is the Julia way of ensuring that I pass a valid 
> probability to my function (figure between 0 and 1). Please do not tell me 
> that I am supposed to use @assert statements x)
> I would feel that a new type would be the cleanest way to do so?
>
> Best,
>
> Kevin 
>
> On Saturday, 11 June 2016 04:37:32 UTC+2, Jeffrey Sarnoff wrote:
>>
>> Hi Kevin,
>>
>> Right questions, different way.
>>
>> Julia's type system is
>>of  shared behavior for sharing behaviors.
>>for specialization as constructive delegation
>>
>> Real is an abstract type that is supertype to some other abstract types 
>>(Integer, Rational, FloatingPoint, FixedPoint, Probability, ...).
>>   
>> [all kinds of]
>>
>> Each immediate subtype of the Real is an abstract type that is supertype 
>> to some type[s].
>> For every individual immediate subtype of Real,  that individual is 
>> supertype to abstract types and/or/orelse to concrete types.
>>Bool <: 
>> Integer <: Real
>>   Union{ Int32, Int64 } <: Signed <: Integer <: Real
>>   Union{ Rational{Int32}, Rational{Int64} } <: Rational <: Real
>>
>>*note that ..currently.. there is not*  Integer <: Rational 
>> <: Real,
>>as ..currently.. all type-based inheritance may associate a 
>> concrete type with an abstraction
>> and that abstraction may be elaborated as a long chain 
>> linking single supertypes
>> or may associate a concrete type with the concretion of concrete 
>> constituents given as its field's types
>> orelse carry some of both manner of information, an enfolding of 
>> the elaborative and the constitutive.
>> 
>> in the early Summer of 2016:
>> Single inheritance of abstract type, and an inheriting abstract type 
>> may itself be inherited.
>> One single inheritance of an abstract type by a Concrete type, 
>>  and the same, jointly or independently for  each of its 
>> concretely typed fields.
>> Any type, abstract or concrete can be defined with one or more 
>> parameters (a parameterized type),
>>  each distinct value(s of the tuple) of the parameter constitutes 
>> a uniquely defined type,
>>  there is support for specifying manner of co-action and 
>> interaction for parameterized type 'siblings',
>>  as there is for specifying the interworking of types and 
>> intraworkings of values of a single type.
>>
>> The architects know how to let abstract types be functionally 
>> dispatchable into, just as sqrt(x::Int64) and sqrt(x::Float64) are 
>> dispatched into specializations of sqrt() for a Int64 or for a Float64 
>> argument.
>> The mechanism is being rethought so that a better, more widely useful way 
>> obtain (does this and makes
>> it easy to process with and fully support software interface protocols -- 
>> and enforce api constraints).
>>
>> Meanwhile "inheriting from Real" does give the type fallback processing 
>> for basic mathematical ha

Re: [julia-users] Re: Defining a new numeric type with minimal effort

[Kevin Kunzmann]

Sorry for spamming,

but let me reduce this to it's actual core - forget about probability. what 
I want to do is

immutable MyType{T<:Real}
  val::T
  function MyType(x::T)






On Saturday, 11 June 2016 07:54:42 UTC+2, Kevin Kunzmann wrote:
>
> Hey,
>
> thanks for sticking with me ;)
>
> I am, however, a little bit confused now (seems that oo and parallelism 
> are the hardest to grasp in julia).
>
> I see that '+' was a bad example. So my error was, that I did not name the 
> field correctly, as 'Real' is expecting it to be named 'val'? Jeez, if this 
> is true then how is one ever going to 'inherit correctly' from a 
> complicated abstract type? There is no way of telling which fileds are 
> accessed how by all methods operating on that type x)
>
> So, put simply: What is the Julia way of ensuring that I pass a valid 
> probability to my function (figure between 0 and 1). Please do not tell me 
> that I am supposed to use @assert statements x)
> I would feel that a new type would be the cleanest way to do so?
>
> Best,
>
> Kevin 
>
> On Saturday, 11 June 2016 04:37:32 UTC+2, Jeffrey Sarnoff wrote:
>>
>> Hi Kevin,
>>
>> Right questions, different way.
>>
>> Julia's type system is
>>of  shared behavior for sharing behaviors.
>>for specialization as constructive delegation
>>
>> Real is an abstract type that is supertype to some other abstract types 
>>(Integer, Rational, FloatingPoint, FixedPoint, Probability, ...).
>>   
>> [all kinds of]
>>
>> Each immediate subtype of the Real is an abstract type that is supertype 
>> to some type[s].
>> For every individual immediate subtype of Real,  that individual is 
>> supertype to abstract types and/or/orelse to concrete types.
>>Bool <: 
>> Integer <: Real
>>   Union{ Int32, Int64 } <: Signed <: Integer <: Real
>>   Union{ Rational{Int32}, Rational{Int64} } <: Rational <: Real
>>
>>*note that ..currently.. there is not*  Integer <: Rational 
>> <: Real,
>>as ..currently.. all type-based inheritance may associate a 
>> concrete type with an abstraction
>> and that abstraction may be elaborated as a long chain 
>> linking single supertypes
>> or may associate a concrete type with the concretion of concrete 
>> constituents given as its field's types
>> orelse carry some of both manner of information, an enfolding of 
>> the elaborative and the constitutive.
>> 
>> in the early Summer of 2016:
>> Single inheritance of abstract type, and an inheriting abstract type 
>> may itself be inherited.
>> One single inheritance of an abstract type by a Concrete type, 
>>  and the same, jointly or independently for  each of its 
>> concretely typed fields.
>> Any type, abstract or concrete can be defined with one or more 
>> parameters (a parameterized type),
>>  each distinct value(s of the tuple) of the parameter constitutes 
>> a uniquely defined type,
>>  there is support for specifying manner of co-action and 
>> interaction for parameterized type 'siblings',
>>  as there is for specifying the interworking of types and 
>> intraworkings of values of a single type.
>>
>> The architects know how to let abstract types be functionally 
>> dispatchable into, just as sqrt(x::Int64) and sqrt(x::Float64) are 
>> dispatched into specializations of sqrt() for a Int64 or for a Float64 
>> argument.
>> The mechanism is being rethought so that a better, more widely useful way 
>> obtain (does this and makes
>> it easy to process with and fully support software interface protocols -- 
>> and enforce api constraints).
>>
>> Meanwhile "inheriting from Real" does give the type fallback processing 
>> for basic mathematical handling,
>> and also encourages some reimplementation, if only to delegate the 
>> calculation to the type's value field.
>> Multiplying two probabilities as reals gives a result that smaller than 
>> either (or equal to smaller of the two),
>> which is not what happens to the probability of a win when more skilled 
>> players join in the effort.
>>
>> Enjoy,
>>
>> Jeffrey
>>
>>  
>>
>>
>>
>>
>>   
>> There is desire an

Re: [julia-users] Re: Defining a new numeric type with minimal effort

[Kevin Kunzmann]

Hey,

thanks for sticking with me ;)

I am, however, a little bit confused now (seems that oo and parallelism are 
the hardest to grasp in julia).

I see that '+' was a bad example. So my error was, that I did not name the 
field correctly, as 'Real' is expecting it to be named 'val'? Jeez, if this 
is true then how is one ever going to 'inherit correctly' from a 
complicated abstract type? There is no way of telling which fileds are 
accessed how by all methods operating on that type x)

So, put simply: What is the Julia way of ensuring that I pass a valid 
probability to my function (figure between 0 and 1). Please do not tell me 
that I am supposed to use @assert statements x)
I would feel that a new type would be the cleanest way to do so?

Best,

Kevin 

On Saturday, 11 June 2016 04:37:32 UTC+2, Jeffrey Sarnoff wrote:
>
> Hi Kevin,
>
> Right questions, different way.
>
> Julia's type system is
>of  shared behavior for sharing behaviors.
>for specialization as constructive delegation
>
> Real is an abstract type that is supertype to some other abstract types 
>(Integer, Rational, FloatingPoint, FixedPoint, Probability, ...).
>   
> [all kinds of]
>
> Each immediate subtype of the Real is an abstract type that is supertype 
> to some type[s].
> For every individual immediate subtype of Real,  that individual is 
> supertype to abstract types and/or/orelse to concrete types.
>Bool <: 
> Integer <: Real
>   Union{ Int32, Int64 } <: Signed <: Integer <: Real
>   Union{ Rational{Int32}, Rational{Int64} } <: Rational <: Real
>
>*note that ..currently.. there is not*  Integer <: Rational <: 
> Real,
>as ..currently.. all type-based inheritance may associate a 
> concrete type with an abstraction
> and that abstraction may be elaborated as a long chain linking 
> single supertypes
> or may associate a concrete type with the concretion of concrete 
> constituents given as its field's types
> orelse carry some of both manner of information, an enfolding of 
> the elaborative and the constitutive.
> 
> in the early Summer of 2016:
> Single inheritance of abstract type, and an inheriting abstract type 
> may itself be inherited.
> One single inheritance of an abstract type by a Concrete type, 
>  and the same, jointly or independently for  each of its 
> concretely typed fields.
> Any type, abstract or concrete can be defined with one or more 
> parameters (a parameterized type),
>  each distinct value(s of the tuple) of the parameter constitutes 
> a uniquely defined type,
>  there is support for specifying manner of co-action and 
> interaction for parameterized type 'siblings',
>  as there is for specifying the interworking of types and 
> intraworkings of values of a single type.
>
> The architects know how to let abstract types be functionally dispatchable 
> into, just as sqrt(x::Int64) and sqrt(x::Float64) are dispatched into 
> specializations of sqrt() for a Int64 or for a Float64 argument.
> The mechanism is being rethought so that a better, more widely useful way 
> obtain (does this and makes
> it easy to process with and fully support software interface protocols -- 
> and enforce api constraints).
>
> Meanwhile "inheriting from Real" does give the type fallback processing 
> for basic mathematical handling,
> and also encourages some reimplementation, if only to delegate the 
> calculation to the type's value field.
> Multiplying two probabilities as reals gives a result that smaller than 
> either (or equal to smaller of the two),
> which is not what happens to the probability of a win when more skilled 
> players join in the effort.
>
> Enjoy,
>
> Jeffrey
>
>  
>
>
>
>
>   
>     There is desire and activity intending 
>
>
>  
>
>
>
>which is not the same as red marbles are a color of Marbleness 
> sculpted of a Material inheritance.
>  types 
>Integers are Real, Rationals are Real  Integers are not Rationals
>
>
> (you are reading how it is 
>
> On Fri, Jun 10, 2016 at 6:15 PM, Kevin Kunzmann  > wrote:
>
>> Hey Jeffrey,
>>
>> it's been a while, thx for the answer. I see that this would be working. 
>> However, what about min, max, sin, etc.? I do not want to re-implement all 
>> elementary functions for the Probability type. There must be some way to 
>> inheri

[julia-users] Re: Defining a new numeric type with minimal effort

[Kevin Kunzmann]

Hey Jeffrey,

it's been a while, thx for the answer. I see that this would be working. 
However, what about min, max, sin, etc.? I do not want to re-implement all 
elementary functions for the Probability type. There must be some way to 
inherit the behaviour of the abstract supertype "Real". I guess I am 
missing something fundamental about the type system here. 

I felt tat something like

type Probability{T<:Real} <:Real
p::T
end

import Base.convert

convert{T<:Real}(::Type{T}, x::Probability) = convert(T, x.p)
convert{T1<:Real, T2<:Real}(::Type{Probability{T1}}, x::T2) = 
Probability(convert(T1, x))


should do the job as now any Probability can be converted to any concrete 
subtype of Real and "+" shoud be implemented there ;)
Very strange, how does Julia handle inheritance at all???

Best, 

Kevin


On Monday, 29 February 2016 23:45:35 UTC+1, Jeffrey Sarnoff wrote:
>
> Kevin,
>
> If all that you ask of this type is that it does arithmetic, clamps any 
> negative values to zero, and clamps any values greater than one to one, 
> that is easy enough. Just note that arithmetic with probabilities usually 
> is more subtle than that.
>
> import Base: +,-,*,/
>
> immutable Probability <: Real
>  val::Float64
>
>  Probability(x::Float64) = min(1.0, max(0.0, x))
> end
>
> (+){T<:Probability}(a::T, b::T) = Probability( a.val + b.val )
> (-){T<:Probability}(a::T, b::T) = Probability( a.val - b.val )
> (*){T<:Probability}(a::T, b::T) = Probability( a.val * b.val )
> (/){T<:Probability}(a::T, b::T) = Probability( a.val / b.val )
>
> You need conversion and promotion if you want to mix Float64 values and 
> Probability values: 2.0 * Probability(0.25) == Probability(0.5).
>
> On Sunday, February 28, 2016 at 10:33:07 AM UTC-5, Kevin Kunzmann wrote:
>>
>> Hey,
>>
>> I have a (probably) very simple question. I would like to define 
>> 'Probability' as a new subtype of 'Real', only with the additional 
>> restriction that the value must be between 0 and 1. How would I achieve 
>> that 'Julia-style'? This should be possible without having to rewrite all 
>> these promotion rules and stuff, is it not? 
>>
>> Best Kevin
>>
>

[julia-users] Defining a new numeric type with minimal effort

[Kevin Kunzmann]

Hey,

I have a (probably) very simple question. I would like to define 
'Probability' as a new subtype of 'Real', only with the additional 
restriction that the value must be between 0 and 1. How would I achieve 
that 'Julia-style'? This should be possible without having to rewrite all 
these promotion rules and stuff, is it not? 

Best Kevin

[julia-users] Re: Julia installer does not put METADATA in user home

[Kevin Kunzmann]

Saved my day, thanks!

On Wednesday, 19 August 2015 08:26:57 UTC+2, Tony Kelman wrote:
>
> You may need to delete User\.julia and try Pkg.init() again.
>
>
> On Tuesday, August 18, 2015 at 10:33:21 PM UTC-7, Kevin Kunzmann wrote:
>>
>> Hi,
>>
>> I was just trying to use Juno + Julia prebundled package on a seecond 
>> machine (Win 8). It always complains about being not able to establish a 
>> connection.
>> So I tried to install pure Julia first. That works fine and I can start a 
>> Julia session in the command line. However, when I want to update the 
>> METADATA it complains about not finding it. Indeed User\.julia\v0.3 is 
>> empty!
>> How can I set up the correct METADATA structure manually?
>>
>> Best,
>>
>> Kevin
>>
>> Here is my error
>> julia> Pkg.update()
>> INFO: Updating METADATA...
>> ERROR: chdir METADATA: no such file or
>>  in cd at file.jl:11 (repeats 2 times)
>>
>>
>>

[julia-users] Julia installer does not put METADATA in user home

[Kevin Kunzmann]

Hi,

I was just trying to use Juno + Julia prebundled package on a seecond 
machine (Win 8). It always complains about being not able to establish a 
connection.
So I tried to install pure Julia first. That works fine and I can start a 
Julia session in the command line. However, when I want to update the 
METADATA it complains about not finding it. Indeed User\.julia\v0.3 is 
empty!
How can I set up the correct METADATA structure manually?

Best,

Kevin

Here is my error
julia> Pkg.update()
INFO: Updating METADATA...
ERROR: chdir METADATA: no such file or
 in cd at file.jl:11 (repeats 2 times)

Re: [julia-users] type checking arrays

[Kevin Kunzmann]

Great, thanks - that makes so much more sense x)

On Tuesday, 18 August 2015 10:10:40 UTC+2, Milan Bouchet-Valat wrote:
>
> Le mardi 18 août 2015 à 00:37 -0700, Kevin Kunzmann a écrit : 
> > Hi guys, 
> > 
> > So, I recently revisited Julia and fooled around a bit with Julia 
> > Box. Amazing - this looks like the language I never actually dared 
> > dreaming of ;) Keep up the greedy work! 
> > 
> > That being said, my question might be dumb, but I am struggling with 
> > the type system of Julia. I want to guarantee that the arguments to a 
> > function are numerical arrays of dimension 1 - how would I best do 
> > that in Julia? The problem is that 
> > 
> > Array{Number, 1} 
> > 
> > exists as a type, but when I get the type system right it should not 
> > have any subtypes except union. Especially 
> > 
> > Array{Float64, 1} <: Array{Number, 1} 
> > 
> > evaluates to ' false'. I think I get why this is implemented the way 
> > it is, however, would it not be most intuitive to have something like 
> > 
> > function f(x::Array{Number, 1}) 
> > x 
> > end 
> > 
> > 
> > What would be the 'Julian' way of doing this? 
> f{T<:Number}(x::Array{T, 1}) or 
> f{T<:Number}(x::Vecotr{T}) 
>
> You're hitting a subtle point which has to do with covariance vs. 
> invariance of types. This part of the manual should make it clearer, 
> but feel free to ask for more explanations: 
> http://docs.julialang.org/en/latest/manual/types/?highlight=covariance# 
> parametric-composite-types 
> <http://docs.julialang.org/en/latest/manual/types/?highlight=covariance#parametric-composite-types>
>  
>
>
> Regards 
>

[julia-users] type checking arrays

[Kevin Kunzmann]

Hi guys,

So, I recently revisited Julia and fooled around a bit with Julia Box. 
Amazing - this looks like the language I never actually dared dreaming of 
;) Keep up the greedy work!

That being said, my question might be dumb, but I am struggling with the 
type system of Julia. I want to guarantee that the arguments to a function 
are numerical arrays of dimension 1 - how would I best do that in Julia? 
The problem is that

Array{Number, 1}

exists as a type, but when I get the type system right it should not have 
any subtypes except union. Especially

Array{Float64, 1} <: Array{Number, 1}

evaluates to ' false'. I think I get why this is implemented the way it is, 
however, would it not be most intuitive to have something like

function f(x::Array{Number, 1})
x
end


What would be the 'Julian' way of doing this?

Best,

Kevin