I need a tuple -- it could have internal subtuples to organize subtypes of
a subtype.
The use is to investigate more expressively elaborated and more flexibly
organized alternatives to the current Numeric hierarchy.
I would call allsubtypes(T) on some of my own Abstract types and then
compare/contrast the sets of tuples yielded, and maybe reorganizing a few.
At present, I am considering ways to interweave the hierarchy of division
algebra numerics: Real, Complex, Quaternion, Octonion
with intermixable types of generalized complex numbers: real, complex, dual
(aka elliptic), split (aka double, hyperbolic)
and also hyperduals (duals with two distinct 'imaginary units').
I am looking for nice ways to allow e.g. the 4x1 real vector, 4x4 real and
t2x2 complex matrix representations of a quaternion to be <:
AbstractQuaternion and
to have types+methods so that with an appropriately defined and working
ComplexNumber type, DualNumber type and SplitNumber type
Ideally, a working SplitComplex type obtains with, say
SplitNumber{ComplexNumber{Float64}}
and all of these work without additional mucking around
SplitNumber{Quaternion{T}} works when the parameter s ComplexNumber{
Rational{Int64}}}
Quaternion{HyperDualNumber{T}}} works when the parameter is
Interval{Float32}
sqrt{T<:Quaternion{Float64})(DualNumber{T}) # (I know, setting a param to
be a parameterized Type this way does not work today)
On Wednesday, February 10, 2016 at 4:12:42 AM UTC-5, Milan Bouchet-Valat
wrote:
>
> Le mercredi 10 février 2016 à 00:47 -0800, Jeffrey Sarnoff a écrit :
> > I want to Typename{T,N} as Abstract onlyif Typename.abstract==true,
> > otherwise Typename.abstract==false and I want to treat it as Concrete
> >
> > Milan's solution displays the subtypes immediately. The way it is set
> > up is neat -- but how to pull the targeted type out of the body?
> >
> > I need this to be a callable function that yields a manipulable tuple
> > or vector or tuple of subtuples or etc.
> Could you elaborate a bit? Do you need a tuple, or a tuple type?
>
>
> Regards
>
>
>
> > On Wednesday, February 10, 2016 at 3:26:14 AM UTC-5, Tommy Hofmann
> > wrote:
> > > I think the recursive solution of Milan will give you a finite list
> > > of all subtypes. But the list will contain things like Array{T, N},
> > > that is, a type with a parameter. How do you handle those? Do you
> > > want to count them as abstract or concrete?
> > >
> > > On Wednesday, February 10, 2016 at 9:10:16 AM UTC+1, Jeffrey
> > > Sarnoff wrote:
> > > > Hello Tommy,
> > > >
> > > > OK, putting off inclusion of recursive types ...
> > > > and ignoring all possible values for the parameters of a
> > > > parameterized type unless already explicitly defined (present in
> > > > memory) ...
> > > >
> > > > allsupertypes(T) should be a short list from T to
> > > > supertype(T) to supertype(supertype(T)) .. to Any
> > > >
> > > > allsubtypes(T) seems obtainable
> > > > I can throw things into a tree until the leaves have no
> > > > subtypes, then traverse it; is there a nice way to do that
> > > > implicitly within a function?
> > > >
> > > >
> > > >
> > > >
> > > > On Wednesday, February 10, 2016 at 2:32:35 AM UTC-5, Tommy
> > > > Hofmann wrote:
> > > > > You implicitly assume that a type has only finitely many
> > > > > sub/supertypes, which for arbitrary types is clearly not the
> > > > > case. The simplest example is Any but you can also get this
> > > > > behavior when defining recursive types. More generally, given
> > > > > types TL, TU there is no way of returning all types T with TL
> > > > > <: T <: TU. You can describe this set using TypeVar, but you
> > > > > cannot just write it down.
> > > > >
> > > > > Tommy
> > > > >
> > > > > On Wednesday, February 10, 2016 at 12:50:43 AM UTC+1, Jeffrey
> > > > > Sarnoff wrote:
> > > > > > I see that your definition pours the subtypes from a pitcher
> > > > > > of the poured subtypes. The note about parametric types is
> > > > > > well pointed. -- Jeffrey
> > > > > >
> > > > > > Clearly, the answer is therein. Cloudily, I'm looking.
> > > > > >
> > > > > >
> > > > > > On Tuesday, February 9, 2016 at 3:43:48 PM UTC-5, Milan
> > > > > > Bouchet-Valat wrote:
> > > > > > > Le mardi 09 février 2016 à 12:24 -0800, Jeffrey Sarnoff a
> > > > > > > écrit :
> > > > > > > > Any advice on quick 'n EZ coding of something like
> > > > > > > these?
> > > > > > > >
> > > > > > > > allsupertypes(Irrational) == ( Real, Number, Any )
> > > > > > > >
> > > > > > > > allsubtypes(Integer) == ( BigInt, Bool, Signed,
> > > > > > > Int128,Int16,Int32,Int64,Int8, Unsigned,
> > > > > > > UInt128,UInt16,UInt32,UInt64,UInt8 )
> > > > > > > > abstractsubtypes(Integer) == ( Signed, Unsigned )
> > > > > > > > concretesubtypes(Integer) == (
> > > > > > > BigInt,Bool,UInt128,UInt16,UInt32,UInt64,UInt8,UInt16,UInt3
> > > > > > > 2,UInt64,UInt8)
> > > > > > > Here's a way to get all concretes ubtypes:
> > > > > > > subtypestree(x) = length(subtypes(x)) > 1 ?
> > > > > > > map(subtypestree, subtypes(x)) : x
> > > > > > > [subtypestree(AbstractArray)...;]
> > > > > > >
> > > > > > > You should be able to adapt this to return all abstract
> > > > > > > types instead
> > > > > > > by using isleaftype() (which would better be called
> > > > > > > isconcretetype()?).
> > > > > > > But note there's the special case of parametric types,
> > > > > > > which aren't
> > > > > > > leaf types.
> > > > > > >
> > > > > > >
> > > > > > > Regards
>
