|
|
Re: Why not Hausdorff's ordered pairs
Posted:
Feb 25, 2012 3:01 AM
|
|
On Feb 25, 5:25 pm, Zuhair <zaljo...@gmail.com> wrote:
> On Feb 24, 10:46 pm, Graham Cooper <grahamcoop...@gmail.com> wrote:
>
>
> > On Feb 24, 10:25 pm, Zuhair <zaljo...@gmail.com> wrote:
>
> > > On Feb 24, 2:34 pm, Graham Cooper <grahamcoop...@gmail.com> wrote:
>
> > > > you added the braces around {a} {b} {c} for a reason, so you could
> > > > determine the {position,{data}} order.
>
> > > EXACTLY! what I see it nice about it is how it simplifies sequences
> > > so for example a sequnce S= 7,63, 2
>
> > > Instead of implementing this as S= { {{1},{1,7}} , {{2},{2,63}} , {{3},
> > > {3,2}} }
> > > which is the customary way using Kuratowski pairs based sequence.
> > > We can simplify that to S= { {1,{7}} , {2,{63}} , {3,{2}} } which is
> > > much
> > > simpler really.
>
> > Not in sets it isn't!
>
> > Instead of a duplicate redundancy on the numerical index n,
> > you repeat it n times.
>
> > To remove the duplicate index, you have to slice the index into an n
> > elements set.
>
> > { {3},{3,C} } K Pair
> > VS
> > { {2, 1, 0}, {C} } Z Pair
>
> > K Pairs use SET SUBSTRACTION to identifiy the first ordinate/index
> > Your system uses SET.SIZE>1 member sets to identify the index
>
> > Note in K Pair, Naturals can be represented O(n) {{{{{}}}}}
>
> > where Von Neuman Numbers are size & time expensive O(n^2) for no
> > reason.
>
> > Breaking your 3rd Ordinate down further..
>
> > { { { {} {{}} }, {{}}, {} }, {C} }
>
> > VS K Pairs
> > { { {{{}}} }, { {{{}}}, C} }
>
> > You are forced to construct arbitrary DISTINCT SETS
> > in order to count them to represent the Natural by it's SET SIZE =
> > MEMBER COUNT
>
> > { DIFFERENT, DIFFERENT, DIFFERENT, DIFFERENT } = 4
>
> > In pure sets, this is 4 levels of recursion O(n^2) data structure.
>
> > You couldn't represent a million digits of Pi on a modern computer in
> > your system.
>
> > Herc
> > --http://Matheology.com
>
> Good point! but it fails!!
>
> Your point is that K-pair based sequences works for any ordinal
> assignments given to 1,2,3,4,...., while mine only works if only one
> ordinal is allowed to be singleton and all
> other ordinals are non empty non singletons, so the K-based sequences
> is a more GENERAL implementation than mine, OK your argument is
> correct, but that has nothing to do with SIMPLICITY, Generality of
> implementation in the sense above is different from simplicity, and
> this kind of generalization you are speaking about is actually not
> significant compared to having the nice simpler sequences of
> "unordered pairs". Anyhow I want also to say something about my pairs,
> they don't need slicing as you think, although this slicing works
> perfectly with them and it is a strong condition, but we can have
> alternatives, you see the secret with my pairs is that the symbols
> 1,2,3,4,... must code sets that are well ordered non empty non
> singltons (except one of those symbols is allowed to code a singleton
> set) this doesn't entail that all of them must vary in size as you
> thought.
>
> You can for example code *naturals* as:
>
> 1 = {0,{0}}
>
> 2= {0, {{0}}}
>
> 3= {0, {{{0}}}}
>
> etc...
>
> Now that this coding will work well for my tuples, all of them do have
> the SAME SIZE. Now use this coding with my tuples and you will see
> that they are simpler than the K-based sequences, because with the
> last there is repetition of the ordinal which cause double structuring
> which is redundant by comparison with this notation.
>
> However don't forget your point is only valid for naturals, but when
> you go beyond naturals you cannot really represent ordinals by
> iterated singletons, so you will eventually need some bigger sized
> sets anyway to code these ordinals, for example to code Omega you need
> the set { 0 , {0} , {{0}} , ...} which is of bigger size, so if you
> are to go beyond Omega then definitely the coding system will need
> bigger sizes, so for that sake this benefit would be lost altogether.
> Still K-pairs sequences have a more general implementation range than
> mine, but this is not really important.
>
> Simplicity is another issue, the point is that my tuples can survive
> alternative coding for the ordinals in it that are fairly simple and
> definitely simpler than the double structuring present in the K-based
> pairs. So we can have simpler formulation of my tuples that are
> simpler than any formulation given to ordinals with the K-pairs.
>
> So net results: my tuples are simpler
>
> Zuhair
Ah OK, this is called an associative array in PHP
<?php
$arr = array("foo" => "bar", 12 => true);
echo $arr["foo"]; // bar
echo $arr[12]; // 1
?>
Not something I use, just a bit of syntactic icing in the real world!
Cheers!
|
|
