| ??? 05/19/06 10:23 Read: times |
#116617 - Further elaboration Responding to: ???'s previous message |
Please provide details of the data you're handling.
If it's ASCII-coded, then storing it as pure numbers would obviously be far more efficient! If the data is not an exact multiple of 8 bits, are you currently wasting the extra bits? Could you just "pack" the data? If the data represents a signal varying with time, could you use the difference between successive samples, rather than complete sample? Remember, any compression scheme will require software to implement, and that software will require some RAM to work in. With only 150 bytes, you may find that your compression software uses more RAM than you save by compressing the data! |
| Topic | Author | Date |
| Ram Compression | 01/01/70 00:00 | |
| Elaborate please ? | 01/01/70 00:00 | |
| Ram compression | 01/01/70 00:00 | |
| What kind of data are we looking at ? | 01/01/70 00:00 | |
| Further elaboration | 01/01/70 00:00 | |
| ram compression | 01/01/70 00:00 | |
| Extra bytes | 01/01/70 00:00 | |
| In that case ... | 01/01/70 00:00 | |
| Yes it can | 01/01/70 00:00 | |
| Information | 01/01/70 00:00 | |
| Err... | 01/01/70 00:00 | |
| Hang on a minute | 01/01/70 00:00 | |
| Information vs. Meaning | 01/01/70 00:00 | |
| How about helping rather than ridiculing | 01/01/70 00:00 | |
| NOT ridiculing | 01/01/70 00:00 | |
| syntax error | 01/01/70 00:00 | |
| a loony replies,its all in the entropy. | 01/01/70 00:00 | |
| sparse data | 01/01/70 00:00 | |
| Run-length encoding? | 01/01/70 00:00 | |
| proper run length coding | 01/01/70 00:00 | |
| But how do you know... | 01/01/70 00:00 | |
| slight mistake | 01/01/70 00:00 | |
| By definition! | 01/01/70 00:00 | |
| go outside the box | 01/01/70 00:00 | |
| Or more RAM | 01/01/70 00:00 | |
if 256 byte not sufficient | 01/01/70 00:00 |