
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 Kpair 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 Kbased 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 Kbased 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 Kpairs 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 Kbased > pairs. So we can have simpler formulation of my tuples that are > simpler than any formulation given to ordinals with the Kpairs. > > 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!

