[LOCKSUIT]

if i want to save on memory space and not save IDs, can i save IDs like this when I save info linked to them?

info
info
info
info

instead of

1 info
2 info
3 info
4 info

If you do binary search, you can still know the ID # of em all, right???
For example, if you go 3 DOWN, then this line of whatever is ID 3, your at THREE
Is this possible in python?



Another question: Can I atain 65,025 unique IDs using just 2 charactors in ANSI? 255x255=65025! For example E3, Pv, 7^, @#

Is this the best method? -> say #$ = 55 and 466, well, we can go up incremental like this 0 0, 0 1....55 55, 55 56...here, the 2 ANSI charactors are numbers in 0-255 and i essentially form a number from 0 to hopefully 65025 by putting them next to each other as shown.

[LOCKSUIT]

---now wait, 255255....yet there is only 65,025 combos..........ok, 255 doesn't go up to 999, that's why. but we can go up to like this 255 99
---ah, we can skip IDs above 255 and go up higher to ex. 0255 and 1255 and 2255 up to 255255, which should be 65,025 combos!

? feedback? will both of the things I asked work?

[ivan.moony]

Those are programming questions.

We can store an "array" of items, one after another without key ID. Later, when we need, say third item, we initialize a counter that goes 1, 2, and it stops at 3, returning the address of  the array item to process it as we want. These counters are implemented through something called "loops" in imperative, or "recursions" in functional languages.

For the second question you messed up the numbers. Considering 1 ANSI character occupies exactly one byte (2⁸ = 256 possible different bit combinations), two bytes are capable of storing 2¹⁶ = 65536 possible different bit combinations. How you represent each combination, being two characters, one two-byte integer, or a bit-combination mapped to anything you want, including hexadecimal representation, is completely up to you.

Hexadecimal representations are useful when a user (programmer) is reading on screen raw 8-bit byte information because each byte can be represented by two digits hexadecimal value, 00 being 0, and FF being 255. In your case, it would be more convenient if we represent two-byte information as 4 digits hexadecimal. With hex numbers, each digit represents exactly 4 bits ( 2⁴ = 16 combinations), where 16 bits is leaving us with 16 / 4 = 4 hexadecimal digits. You can say that the stars aligned each hex digit with 4 bits of information.

[LOCKSUIT]

Cool.

Not sure what to do with the 2nd question though.... ;

>I want to stick to ANSI right? Each character I store in ANSI takes 1 byte - 8 bits, (unless you know how I can get that lower).
>ANSI gives me 65536 unique IDs using just 2 characters. After I top out, I will then use 3 characters.
>I'm not sure what you mean by 4 digits, hex, or decimal. All I know is that using 1 characters gives me 255 unique IDs, then using 2 characters I get 65536 more unique IDs, for example 255255 is the 65536th unique ID make up, because it skips some like 77777 since 255 can't go higher. I know you can do stuff with them, like times/add etc, but I don't see a reason that adds more unique IDs to the punch.

[LOCKSUIT]

my code could look like this:

%6 &G Yt
43 Rn J#
"4 H! tT
Op YT ^%
...

here I don't even have to add the Ids of the lines of info, and as for what they link to, each link, well, most, just use 2 charactors (16 bits) to store a link to some ID. For example Op there above may say to go to ID 2

[ivan.moony]

When you store raw data, often you know how long each data item is. If the length of each item is, say 5 bytes, and you need an address of the third item, you calculate <address of the first item> + 5 * 3. But if each item has its own size, you got yourself a bit of trouble if you want to get some middle item. In those cases, it is useful to have another table called index. Index is composed of addresses of items from the first table, and if each address takes 4 bytes, it is easy to extract an address of each item by previous math.

[LOCKSUIT]

I can just do binary search over all stored IDs no? And skip the index that wastes more memory?

[ivan.moony]

Yes, but each item then have to have a fixed known length. And then, knowing the length,  you don't have to have an ID.

[LOCKSUIT]

That no make sense lol...

Is it better for binary search to just say ok I must find ID 27345 and then see that it is 5 digits long and go to the thousands sector place "door" and then go into the hundred sector and then brute force the 99/999 stored there?

Ex. to find 27345 it goes
door 20000
then door 7000
then it looks through brute force all IDs from 7000-7999!

you can imagine it looking like this:


30,000





   7,000

20,000



















1



that'd only require a few um ahem doors, a few bytes to store

[Freddy]

From a programming perspective you have to decide if the processing time of a sequential search is going to be more efficient than an indexed one. And you have to weigh that against gains or losses in memory usage.

What is the defining factor here ? Is it time or memory ?

[LOCKSUIT]

Time is important, and so is memory though. Using 2 characters to achieve a link from 1 node to another node is good atm. 1 character would be too good to be true. And you can't go lower than that even if.

But we are talking about binary search, indexing, brute force now, so back to the discussion:

is binary search the same as indexing or even use indexing?.....is one one faster but more memory wasting for long term? Oh and a 3rd one to the mix, what about my "doors" solution? Or is my solution actually binary search or indexing?

[LOCKSUIT]

****************
****************
****************
errr.....this no make sense.....

If all I have is millions of IDs not even written and only implied, and each has info, then what is there to index? And why can't binary search just do its job without first indexing? See below, we already have 10 IDs....what more could you "index".....just start choping them in half using binary search.....unless it has to create a binary search tree to index the IDs implied.

%6 &G Yt
43 Rn J#
"4 H! tT
Op YT ^%
...

.......if binary search is that tree i see on wiki, where it cuts half of the IDs in half each node it looks to, then, that is the same as my "door idea" where it eliminates options LOL. Isn't it? Isn't it??
****************
****************
****************

[ivan.moony]

Binary search and indexing are advanced lessons. Perhaps you should start with basic programming. Then move onto memory management and pointers. Then binary search and indexes would make more sense.

Binary search works only on sorted data. And data could be sorted many ways, by this or that criteria, by this or that column, even on multiple columns at the same time. Specific sorting is stored into different indexes, handling the same data table. These things seem natural when you pass through basic and more advanced lessons of programming.

Of course, if you deal only with a single column, it could be sorted in place, without an index. But then there is a performance issue: is it faster to insert an item into a middle of list, or it is faster just to append the list, and insert a pointer into index of list.

The subject is very complicated, we are talking about memory management, people are writing thick books about that, and you can understand them only if you learn programming concepts with pointers, which could be understood only if you learn basic programming.

The question is: do you want to learn programming? If you do, there is a moderately long way to understand indexes which begins with basic stuff like program input, output, variable assignment, optional code branching, loops...

[LOCKSUIT]

wait...if we don't wanna look through each sequentially, and just cut the IDs in half using binary search, why can mr. mighty binary searchy just look at thee midpoint element ex. 5573!? It'd have to look through thousands just to find that ID....if it can find that in 1 hit, then it don't need to do my job, i can just look for the ID..right?

[LOCKSUIT]

To rephrase that: If we have IDs 0 to 1 million, and binary search can find ID 500,000 in ONE HIT, then that's all I want lol....I don't need binary search then....this don't make sense though I know it doesn't make sense...

Binary Search is supposed to find the ID I'm looking for. I read online that it first finds the midpoint of all elements. THAT defies the whole logic/point of the problem, it can't find that in 1 hit.

Worse case, it'd have to read through half of the elements.