Questions about Mapping 3digit PAO to Cards and Binary

General Memory Chat
1

Hello all,

I’m quite new to this. I have now a PAO for 00-99. I understand that there are other systems but before exploring them I would like to use PAO for as many of the competitive disciplines as possible just to explore the variety of tasks. While faces, images, and words don’t work this way, binary and cards seem to be map-able onto PAO. Which leads me to my questions: Do people do this, and are there general PAO<->Binary / PAO<-> Card maps of this sort?

Cards

In any case one would need to determine an order of suits. I’ve gone with
1 - Spades
2 - Hearts
3 - Clubs
4 - Diamonds
With the memnonic being: count the number of tips/curves at the top. This doesn’t group black and red suits together, I see advantages and disadvantages in this, though I am left wondering on later compatibility for other systems which I don’t know yet.

Then comes the question, how to map the numbers?
I have seen a proposal here Modifying the Dominic System, PAO and mapping cards of mapping ace-9 from 11-49, and the rest after.

I see for myself systems mapping to 1-52: 1-13 & 14-26, etc.
The disadvantage seems to be that this takes more en/decoding time.

I also see mapping the suits 1-13 onto starting digits 01/21/41/61 or something of the sort.

In all these approaches, 48 of my PAO system go unused. I am left wondering if there is a smarter approach, extracting the binary red/black, or the suits into separate data, chunking them, and placing them separately, or some such thing.

I have found surprisingly little on this, perhaps I’m looking in the wrong places. Are there general thoughts on this? Otherwise I will simply jump the gun and pick one as to not overthink =)

Binary

The same question for binary. How to map it, with my goal being to optimize the saturation of 00-99 digits, while having simple en/decoding steps. Here the en/decoding I would probably have to practice in any case, so I aim for saturation.

Mapping 6 binary digits onto 00-63 would be the canonical approach, here 36 PAO numbers go unused.
One could map 3 digits onto 0-7, and another three onto 0-7 once more, combine them into double octal/decimal digits. This would spread out onto the range 0-77, but encode the same number of binary digits, of course.

I suppose one could go bigger than 6 digits and try to break it down from there. I’ve also thought about compression algorithms in this regard. Any general practices here? In absence, I would probably just shoot for the first approach to avoid overthinking for now.

Thanks in advance!

2 Likes
2

Hi!

Here’s a description of how I mapped cards to numbers for easy reading via the Major system. Not sure if you use that for numbers but I use the same suit to number encoding:

In terms of binary, what you’ve suggested is a great idea. 3 binary digits per chunk, translated to the actual number. 000=0… 111=7. Do this twice and you’ll get a 6 digit binary sequence converted to a 2-digit number between 00-77 (excluding the x8 and x9 numbers.) If you have a 2-digit PAO list, you can store 18 binary digits in one PAO scene.

By the way, the title of your post says “3digit PAO”… Are you looking to expand to a 3 digit system? That opens up lots of new possibilities for data compression per element with 3 decimal digits, 2 cards, and 9 or 10 binary digits per image!

2 Likes
3

Hi Tim, thanks for the on-point reply!

That’s a great write-up, I ended up opting for the card encoding you used an tried it out a little, and it’s great, for sure the best option for me. As for the binary, I will try (and likely stick with) the 3 digit chunks then.

My bad on the 3 digit PAO, it’s only two digits so far (was late), but I have been thinking about expanding yes, also thinking about splitting A into transitive and intransitive verbs or something similar, although after the basic PAO I would probably first trial run a completely different system.

For now it’ll be a lot of practice in many forms. I’ll post once I know how that turned out or I need some further input, again, much appreciate your feedback, this forum is the only connection I have to this hobby so far.

1 Like
4

image
image957×717 48.7 KB

I use the Dominic System PAO to encode eighteen digits (e.g. 010 - 110 - 001 - 100 - 011 - 111) at any particular loci. Converting the given binary digits yields: (26 - 14 - 37) where the mini-scene is created using Person (26) - Action (14) - Object (37).

As my Dominic PAO for 14 = AD = (Jesus - Crucified - Cross) and my 37 = CG = (Che Guevara - Smoking - Cigar), my final image to recall would be: Bart Simpson being Crucified on a Cigar (a most bizarre scene to say the very least).

2 Likes
5

Preface:
I have zero focus (currently) on competitive memorization, so speed does happen, but I don’t maximize for it. If maximal speed is important, this may not be of interest. Apologies if I’m out of place here.

Food for thought:
I use either the hexadecimal system or my Dominic-esque style method to memorize binary.

Easiest, for me, is just using the Dominic method to memorize the entire binary number.

I have all powers of two memorized up to (currently) the 16th power (ie, the 17th bit).

Since maximal speed is not imperative, it’s fairly simple to memorize large strings of binary. If one breaks apart a binary number into 6-bits, you have integers 0-63 for every 6 bits.

That’s one image for every six bits (if you’re using PAO, that translates to
P=6-bits + A=6-bits + O=6-bits = 18 bits

18 bits for one single person/action/object.

You know they’re in 6 bit chunks, so you break 'em up and calculate the values.

Example (randomly generated 18-bits):
010011111111010100

we’ve got:
010011 = 19
111110 = 62
010100 = 20

Here’s the PAO for an 18-bit sequence: 19, 62, 20

That’s one idea. Hexadecimal is another potential way of doing it (since it groups bits into 4-bit “nibbles”).

1 Like
6

I recognize this is the “canonical approach” as you mentioned, so my focus was more on utilizing the numbering system inherent in binary as a starting point.

Remove bits (6 bits to 4, for instance) and we wind up with something like Hex’s 0-F scheme.

But add a bit and the system requires (if one wants an individual image for each) a total of 127 images.

That gives 7-bit chunks.

One PAO = 21 bits

Add another bit and we’re at 255 images for an 8-bit chunk system.
One PAO = 24 bits.

I suspect there would be an algorithmic way to “compress” this further, but I can’t think of a way that would be significantly easier than just using what’s already available (00-63).

Although, I’d like to hear about folks who take that route!

–
Edit:

One thought is for folks who have a 000-999 system, they could expand that by another 24 images to reach 000-1023

At that point every 10 bits would receive its own memory device.
One Person + Action + Object = 30 bits

1 Like
7

@fred2 @beau2am thanks! Yes I’ve in the end opted for the 3,3 binary digits → 2 decimal digit encoding approach, though I am still practicing on cards atm. (slowly on the side).

@beau2am I think that encoding the decimal digits separately (as 3 binary each, rather than 6 for two digits) is much faster for me. I actually don’t think there is any possible compressing method mathematically since we are expecting to memorize perfectly random information. There is a way to spill over between PAO double decimals though, trying to use the 36 unused possibilities of each position; after memorizing 18 binary digits we have 36*3 unused options. Of course it’s probably very hard to find an easy system here… and in the end, as you mentioned, for full saturation we may as well keep adding bits until it fits our decimal system again sufficiently…

I also agree that the 1024 binary makes the triple pao system a bit more tempting, hadn’t thought about that, but that’s far on the horizon for me haha.

edit: though on the compression I have thought about something like a huffman coding tree (useless with unbiased random information), and it led me to wonder about a binary tree memory system

1 Like