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 <[email protected]>
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
> 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
>>>
>>
