u/This-Independent3181

Hi i am CS grad and very new to this stuff. I was exploring photonic memory, that's when i thought why not use refractive index of an material to encode the data. Recently when I was reading about refraction of light i came across how the refractive index is affected by the electrons distribution in the material. So why not say for an single bit you use a small material like few ~nm in range and the material has an shaded region representing 0 and an photo detector as such on the other region representing 1 and the material is enclosed by an material that referact the light. You now apply voltage to the material, an specific voltage changes the electron distribution of the material making the passing light through referact and hit the shaded region or photo detector. This photodetctor then drives an small electric switch which turns on an another light beam that's powered seperately that's used to route the light to the readers photo detector. Say if you have a number of such forming an 8-bit an byte.

Have a doubt say 2 processes P1 and P2. P1 is checking an condition using an while loop and until the flag is set to true it keeps on looping i.e while(flag==false); , this flag can be set to true by P2 process which has executed crticial section, but before it executes flag=true; it needs to execute some logic in the remaining section but the thing is this remaining section needs something from P1 to progress like say P1 being producer and P2 is consumer as such. now P2 sees P1 not produced and goes to sleep(inactive) but P1 is active still spining. Now is this deadlock/livelock. Since from as far i have seen livelock the definition is the processes are active i.e using cpu performing memory operations but not making any progress which fits P1 here. So can 2 process involved in an deadlock such that 1 process can be active while other inactive(not using cpu)?

I would be going straight to the idea,

So a file whether it is text, binary, JPEG all are at the end of the day stored as a stream of bits(1s and 0s).

My basic unit I am dealing here is 10 bits might sound awkward but has a clear reason which will be explained later on.

So for a given file i will be dividing it into chunks each chunk of size 10\*320=3200 bits again the number 320 too has a reason stated later.

So let's dive into one such chunk. Each chunk is 3200 bits wide and my unit is 10 bits so 320 10 bit units exist per chunk.

Now I describe the range since 10 bits so 2^10=1024 so the range would be 0 to (1024)-1=[0-1023].

So each chunk for illustration purpose i represent it in terms of array so say the chunk elements are [10, 23, 1023, 255,......., 512] total 320 elements here the decimal value corresponds to the binary (sequence of bits) 10 bit combination like decimal 10 -> 00000 01010(binary).

After that I construct a comparison map 2 comparison map actually I use 3 states so each comparison can be either of 3 states that is <, >, = each state represented using 2 bit (00, 01, 10).

For the array i first construct the comparison map from the start element compared to all the other elements and another comparison map from the end element i.e last element to rest elements.

for example take a 4 element array [1, 4, 3, 2] so from element 1 the comparison map (1,4), (1,3) , (1,2) and from the end element that is 2 you build (2,3), (2,4) and (2,1) you don't include as (1,2) already exists so you end up with [<,<,<] and [>, >].

After this step you then sort the array destroying the ordering of the elements.

The next step is to give this array (which is now sorted) an index. This index is derived from :

The array length is 320 elements and range of each element is [0-1023] and the arrays have sorted order (ascending) constraint, repitations allowed

Then the total number of possible arrays that can be constructed is using combinatronics(nCr) :

(n+m-1)C(n) where,

n = number of elements = 320

m = number of possible states of each element i.e basically the range = 1024

So (320+1024-1)C(320)= (1343)C(320)

Now taking log (base 2):

log(base 2)[(1343)C(320)] = ~ 1060 bits.

So the index is 1060 bits.

This index bit basically indexes to the sorted array that was derived from the orginal unsorted array.

This step repeated for all the chunks.

All this happens at encoder side, Now coming to decoder side of things:

The decoder gets 2 things one is:

1. The index (1060) bits.

2. The 2 comparison map each map costs 2x320=640 bits so 2 map => 2x640=1280 bits.

Total bits transmitted/stored = 1060+1280 = 2340 bits.

The decoder now uses the index, the decoder doesn't store 2\^1060 arrays and then index to it rather it uses pascal triangle to reconstruct the sorted array from the given index.

Once reconstructed it then uses the 2 comparison map to recover the original ordering.

Now coming to reason for n=320 and range = \[0-1023\].

The n (length of the array) :

The length of the array plays a crucial role here even length and odd length arrays behave differently, the 2 comprasion map built can be used to reconstruct the orginal ordering from the sorted array exactly only if the length of the array is even if odd the decoder faces ambiguity when reconstructiong this failing a exact reconstruction. So n had to be even.

why 320? I initially tried with n=64, 128, 256 and range [0-15] nibble (4 bits), [0-61] 6 bits, [0-255] byte (8 bits) but couldn't get the proper efficiency the compression ratios were hanging around 80%, 85%, 90% couldn't find optimal ratio that's when I came to n=320 and range [0-1023]

Raw data size = 10 bits x 320 = 3200 bits.

My compression = 1060 bits(index) + 1280 bits(comparison map) = 2340 bits.

Ratio 2340/3200 = ~0.74.

So compression ratio of 0.74. So ~74% of the orginal size.

Hi guys CS grad here,

I would be going straight to the idea,

So a file whether it is text, binary, JPEG all are at the end of the day stored as a stream of bits(1s and 0s).

My basic unit I am dealing here is 10 bits might sound awkward but has a clear reason which will be explained later on.

So for a given file i will be dividing it into chunks each chunk of size 10*320=3200 bits again the number 320 too has a reason stated later.

So let's dive into one such chunk. Each chunk is 3200 bits wide and my unit is 10 bits so 320 10 bit units exist per chunk.

Now I describe the range since 10 bits so 2^10=1024 so the range would be 0 to (1024)-1=[0-1023].

So each chunk for illustration purpose i represent it in terms of array so say the chunk elements are [10, 23, 1023, 255,......., 512] total 320 elements here the decimal value corresponds to the binary (sequence of bits) 10 bit combination like decimal 10 -> 00000 01010(binary).

After that I construct a comparison map 2 comparison map actually I use 3 states so each comparison can be either of 3 states that is <, >, = each state represented using 2 bit (00, 01, 10).

For the array i first construct the comparison map from the start element compared to all the other elements and another comparison map from the end element i.e last element to rest elements.

for example take a 4 element array [1, 4, 3, 2] so from element 1 the comparison map (1,4), (1,3) , (1,2) and from the end element that is 2 you build (2,3), (2,4) and (2,1) you don't include as (1,2) already exists so you end up with [<,<,<] and [>, >].

After this step you then sort the array destroying the ordering of the elements.

The next step is to give this array (which is now sorted) an index. This index is derived from :

The array length is 320 elements and range of each element is [0-1023] and the arrays have sorted order (ascending) constraint, repitations allowed

Then the total number of possible arrays that can be constructed is using combinatronics(nCr) :

(n+m-1)C(n) where,

n = number of elements = 320

m = number of possible states of each element i.e basically the range = 1024

So (320+1024-1)C(320)= (1343)C(320)

Now taking log (base 2):

log(base 2)[(1343)C(320)] = ~ 1060 bits.

So the index is 1060 bits.

This index bit basically indexes to the sorted array that was derived from the orginal unsorted array.

This step repeated for all the chunks.

All this happens at encoder side, Now coming to decoder side of things:

The decoder gets 2 things one is:

1. The index (1060) bits.

2. The 2 comparison map each map costs 2x320=640 bits so 2 map => 2x640=1280 bits.

Total bits transmitted/stored = 1060+1280 = 2340 bits.

The decoder now uses the index, the decoder doesn't store 2^1060 arrays and then index to it rather it uses pascal triangle to reconstruct the sorted array from the given index.

Once reconstructed it then uses the 2 comparison map to recover the original ordering.

Now coming to reason for n=320 and range = [0-1023].

The n (length of the array) :

The length of the array plays a crucial role here even length and odd length arrays behave differently, the 2 comprasion map built can be used to reconstruct the orginal ordering from the sorted array exactly only if the length of the array is even if odd the decoder faces ambiguity when reconstructiong this failing a exact reconstruction. So n had to be even.

why 320? I initially tried with n=64, 128, 256 and range [0-15] nibble (4 bits), [0-61] 6 bits, [0-255] byte (8 bits) but couldn't get the proper efficiency the compression ratios were hanging around 19%, 16%, 9% couldn't find optimal ratio that's when I came to n=320 and range [0-1023]

Raw data size = 10 bits x 320 = 3200 bits.

My compression = 1060 bits(index) + 1280 bits(comparison map) = 2340 bits.

Ratio 2340/3200 = ~0.74.

So compression ratio of 0.74. So ~75% of the orginal size.