Should loci be considered "elements" of a system if they don't encode information?

General Memory Chat
, ,
1

I’ve been thinking about this for a while now and I’m not sure I have my thoughts completely organized on it so forgive my tendancy to ramble, but I wanted to toss this out as a starting point… Should loci be considered “elements” when evaluating a system?

There is a ton of discussion about new ideas to reduce the amount of loci needed to memorize X digits or number of cards. New ways to get at data compression are tossed around pretty regularly. There are all kinds of suggestions of new categories or visual element types that can be used within a scene to encode more data so that you only need a handful of loci to memorize a large data set.

On the other hand, simpler scenes with less to encode and decode are much easier to remember, but they require more loci if used for long sequences…

First off, some clarification on terms:

I like to define an “element” as the smallest pre-determined attribute of an image that encodes information, so standard things like person identity, action, object identity, or more esoteric things like color, emotion, texture, vehicle, or some kind of other categorical element. If it is an attribute that needs to be specifically considered and recalled in order to encode or decode information with it, I consider it an “element.” “Images” are made of “elements.” “Scenes” are made of one or more “images” interacting (usually at a loci). A “System” is a way to use scenes, images, elements, and (usually) loci to memorize information.

I usually evaluate systems on the basis of how many digits or cards can you compress into a single element. This forms the basis of how effective I think a system can be. Then I consider the workload needed to learn to pre-associate the numbers or cards to those elements or element types. Finally I look at how difficult scene construction would be and whether its practical to combine elements in the way that is being suggested.

The loci or the amount of loci needed was never really factored in for me when thinking about how many elements or element types were needed to build a system or in how difficult a system would be to use. It was just an assumed factor that expanded or shrunk as needed depending on how much data needed to be encoded. Now though, I wonder if the number of loci should be more heavily weighed when considering a system or if loci should count as elements since they are things that need to be pre-determined as well. The thing is, usually loci aren’t “elements” in my previously defined way. They don’t encode information. (I realize that they actually can and do with techniques like Variable Spacial Encoding where loci and their orientation matter, and maybe that should be a consideration for the 3-card approach… Is it really a true 3-card system if there are two elements needed to encode those cards if we consider how the loci functions as its own individual element… but for the purposes of this I’m looking at traditional use of loci as just scene settings.)

My thinking is that while you need to consider how many loci will be needed to be built and memorized to fluency in order to use the system, they are different than the actual elements that do the encoding. There is no variability in the loci used in this way. Once you learn the loci sequence, you’re set. The loci will always appear in the same order every time you use that palace. So I think you should consider the amount of loci needed, but as a one-time cost to pay. The encoding elements are dual cost by nature. First the cost to learn their associated number or cards, and then an additional cost every time during memorizing because they won’t always appear in the same order with the same interactions at the same loci.

Not 100% sure where I’m ultimately going with this, or what the implications are for evaluating and building new systems, but I definitely am interested in other thoughts on this topic.

6 Likes
Value-value-suit image connected to suit person in location
Value-value-suit image connected to suit person in location
2

You hit something I was thinking of a few days ago as well: are block strategies any better than additional elements per image? You still gotta focus on them during encoding and retrieve them during recall. What you mentioned about whether the 3-card system should be regarded as such is like asking if the Shadow System should be regarded as a 2-card method since Variable Image Stacking requires thinking. It’s a valid question. Why would the memory palace not be regarded as an element if it encodes info and needs to be analyzed?

I believe the difference between an element and a block is that the former adds to the scene, while the latter changes how you create the scene. Blocks just use something that would already be there anyways, but things like effects are added to the image in a way that demands justification.

For instance, if you use effects to determine the suits of cards, like blood is red suit first and black paint is black suit first, you would build a story as you memorized, “Sonic (027) is covered in blood because he had been stabbed. As his last action, he explodes a bomb (939) to kill Simba (039), but it was actually a fake one carrying black paint, which dirts him…” Notice how the effects end up getting enmeshed in the narrative itself. They demand explanations, or else they’d be forgotten. What is memorable about Sonic covered in blood exploding a bomb around Simba covered in black paint? Why isn’t Sonic covered in black paint instead? Are both black? Are both red? Effects aren’t memorable by themselves.

Blocks like Variable Image Stacking or Variable Spacial Encoding, however, are totally different. They don’t demand any justification whatsoever. For example, if you apply the shadow system, and the same images appear again, you could imagine Sonic exploding a bomb to kill Simba. If the cards representing the lion are red first, then you move to the next locus. Your story would be quite simpler: “Sonic is eager to kill Simba, so he detonates a bomb.” You don’t need to worry about remembering that Simba is the last image in the locus. It doesn’t demand an explanation. You used the story itself to encode information. The same thing works for Variable Spacial Encoding: why is the image at the left bottom of the locus? Idk, it’s just there. You visualize in your mind, and the image is in the right place. There is no need to add to the story, “it’s in the bottom left because Sonic is depressed, and he stays on the left because he is left-handed, which makes this side his favorite.”

In summary, effects are elements, and bad ones, because they make images more convoluted and repeat too many times (how many times would you need to imagine someone is covered in blood because they got stabbed?). However, most blocks reduce the number of images and use something that is already present in the memorization.

For normal loci, though, I would not regard them as elements. They should be taken into consideration as one of the costs of a system, but they don’t matter much since they’re just a one-time cost, as you said. In fact, they have the opposite relationship with accuracy: more loci to encode the same amount of info makes it more memorable since the images are probably simpler, but more elements to encode the same thing is almost always bad.

One consequence of these definitions is that actions would resemble more a block than an element. Think about it: we are always using them, so why not to use them to encode information? That seems to be the reasoning behind any block strategy. It has a few problems though:

  1. There aren’t many unique actions
  2. It feels more intuitive and more memorable to imagine characters acting according to their essence, rather than a predetermined list
  3. Just like the previous problem, sometimes the action doesn’t match the object well
2 Likes
3

Another thing is, palaces can be multi-use across systems and event disciplines, so there isn’t always a need for custom built palace for every new system.

4

I think you hit on it perfectly. This is where I think I was trying to get to in my own reasoning but couldnt find a way to make it click in my mind.

This makes total sense.

Yeah, I think the idea of adding something that wouldnt already be there is key. I can buy this reasoning to soften my evaluation of blocks as elements. Maybe they would count as like half an element for me? Still need to actively consider them for encoding purposes, but dont need to justify them existing or somehow make them fit the scene story.

Kind of. Except usually in context of PAO they are fully pre-associated with specific content. I agree that they are sometimes the weakest of the elements when they have to be pre-associated. Its much easier for me to remember and takes less time to visualize a natural fit action that doesnt encode data but just serves to link elements than being shoehorned into an arbitrary action because thats what the encoded content dictates.

This is where I’m starting to gravitate towards. Pay the one-time up front cost of creating more and possible longer palaces so that the process is simpler after that.

2 Likes
5

This leads to an interesting question: how many blocks may be added before they become as slow as extra elements? Are blocks faster or slower than using additional loci? What types of blocks are faster?

So are the colors in the Shadow System: red first is pre-associated with last image in the locus and black first is pre-associated with the rest of the positions. The only difference is that, in PAO, there are 100 predetermined connections, while there are just 2 in Variable Image Stacking.

That indeed seems to be the best option if the goal is speed only, but for amount memorization the question remains. For instance, once I memorized 10,122 digits by placing 14 digits per locus using 2-digit PA lists. That made me spend 723 loci instead of 1,687. The images were more crowded, but it saved me tons of loci. Had I put just 4 or 6 digits per image, would that require fewer reviews to the point I would have been better off building more places upfront? I’m not sure.

Another question would be if having fewer images per locus is really always the most memorable option. Admittedly, there is a benefit to having more than a single image: there are more possible interactions. After how many images does it start becoming more confusing than memorable? 2? 3? Is there any way to make the interactions inside the locus hold more images without increasing the difficulty? For instance, that idea of continuous memory palaces seems to do just that, what other strategies may be possible? Applying them may be even more efficient than building more loci since you save time from construction and reviewing (we gotta maintain the palaces sharp).

1 Like
6

@TheHumanTim & @Mike4,

You might want to check in to my analysis of what you guys are talking about. I think I came up with some good answers that break a visual image (a block) into five possible datatypes and how they can be combined and added to through a story technique. If you use a PAO, that’s a peg system instead. I’d appreciate some good discussion on that.

You can read the SEA-IT thread here or in my book. I also did an analysis on efficiency of combining elements but not for cards but for 2-digit and 3-digit systems.

I have tried to make the discussion simple when possible and given examples as much as possible. Let me know if you have a comment. And as far as the topic heading goes, yes, I’ve found in my personal systems that a terrain/locus is an element that carries a distinctly unique personality when used to create a visual image.

Doug

3 Likes
7

Thanks for the suggestion, @thinkaboutthebible! I’ve been meaning to hop back into your books, Doug, and I still owe you a couple amazon reviews!!

1 Like
8

I like your differentiation between one-time system establishment costs (I call them pre-work costs) AND repeated-use costs (each time you memorize a long number or deck).

Also like your differentiation with ordering. Loci are usually used in the same order. P or A or O (if you are using a PAO system) are used in a random order.

Given that loci recall is free (only a pre-work cost), encoding at a station takes 3 recalls (P A O), and 3 links. Six mental “ops”; let’s call them MOPS (reflecting computer science I guess). Does this seem right? To counter my own premise though, it seems like the 3 recalls could become essentially free with enough practice; they become pre-work cost.

(I’m sure this has been analyzed and commented on before.)

1 Like
9

Please ignore the following 2 cents which I indeed do have:

Via abstraction, any MOP[1] is theoretically capable of cost reduction to infinitesimal amounts.

  1. I like this term. ↩︎

10

Yeah, I like this idea of pre-work vs. active costs.

The 3 recalls could definitely become reflexive. Thats the point of drilling for recognition only as part of a practice routine. Like getting fluent with reading words vs. having to sound out the letters in every one.

1 Like
11

Economies of scale is key to your whole debate. Looking at a specific example say memorizing a single deck of cards with the simple tools of a system of 52 x loci and a system of 52 x card pegs, you have a few options. Let’s examine the possibilities that are at the end of the spectrum first. One could either use 1 x locus (Note: locus is singular and loci is plural) with 52 x card pegs arranged in the order they are to be recalled in it, or I have 52 x loci (representing 1 locus for each card peg)? Other alternatives may be 17 loci for a PAO system = 51 cards tagging the last card peg to the last scene being contrived. If 4 x elements or (4 x playing cards) are placed at each locus, then 13 x loci will suffice.

Your question as to whether loci should be considered as ‘elements’ or not is a thought provoking question and my immediate answer in short to the question is, it depends! For example, someone who uses pegs as surrogates for loci the answer to your question would be a definitive - Yes! For example, not everyone uses stations around their homes as loci in such an exercise. I for one, much prefer using a peg word system as opposed to a locus at each of the stations 1 - 52, probably a habit of first having learnt the system of how to recall a deck of playing cards from the “Harry Lorayne” book, where he first teaches you 52 peg words from 1 - 52 using the Major System and thereafter, shows you how to link card peg words to each of these 1 - 52 peg words taught? So in this type of example, LHS (positional peg word) = RHS (card peg word), I would definitely say that the “loci” (or positional peg words) are “elements”. Of course, you may not accept that positional pegs as explained by Harry Lorraiyn are “loci” to commence with and there could be some argument that strictly speaking they aren’t. This is why I like the type of question you are asking as it affords us the opportunity to investigate the concepts we are all familiar with under different lenses.

Answering your question as to whether ‘loci’ in the sense of the Roman Room type model are elements, I would tend to answer strictly speaking - No! But, and here’s the kicker I use to define whether the “loci” placeholders are “elements” or not, is whether I can prescribe a NUMBER to them and whether they follow a natural sequence that given what number “n” is, we can clearly define what number “n + 1” is. So a person who uses the Periodic Table of elements as Loci pegs who is told that Bromine is element #35, would immediately know that Krypton is peg #36, being Krypton and is visualized maybe as “Superman”. But on the otherhand, where stations are not numerically able to be deciphered, such as an “imaginary walk around one’s house”, those ‘loci’ at least to my definition used, wouldn’t constitute ‘elements’. Confusing to some maybe? but that’s at least how I figure it out??

1 Like
12

I think you are right so I guess I’m not ignoring your 2 cents. The larger and more complex the codebook is, the smaller the size of the messages can. If my codebook has 86743345683484848 paired with Paris, linking Paris to a loci is simple and only 1 MOP. Encoding and Decoding gets more difficult though, which is probably why we are at 3 digit systems or less. Spies (and computer programs) can refer to written-down codebooks, memory workers cannot. You can internalize a lot of subtleties about information theory (Shannon-sense) through practical implementation of memory systems

Also the maintenance (i.e. review of system) costs go up quite a bit for complex systems and can be daunting if you want to start new things. So practicality becomes crucial. An old quote attributed to Einstein (perhaps): “In theory there is no difference between theory and practice. In practice there is.”

1 Like
13

I assume you’re referring to one time pads.

Otherwise I don’t see why a memory worker couldn’t memorize a "codebook.

As long as there are patterns, there are functions (and ergo abstractions) available for decoding.

The only exception is with true randomization.

In that case, the best one can do is memorize tiny patterns (eg, systems that encode using 1, 2, or 3 elements) to reduce the burden.

But the cost of implementation grows in a non-linear manner when information is truly randomized.

That’s why there isn’t a 4 digit system.
And 5 is right out.

However, any information that isn’t truly random has the (theoretical) advantage of acquiescing to abstraction. No?

1 Like
14

It’s an interesting concept to ponder!

2 Likes