Reduce space requirements for the entries property
holroy opened this issue · 2 comments
I've been thinking about how it'll look when you've tracked your progress for some time, with how many rows you'll get in the entries property of a given habit. Today it occurred to me that this could be drastically used by switching the format slightly, and start using binary numbers for tracking if a habit has been done in a given month.
The gist of the idea is that you store one 32-bit number for each month you're tracking, where each bit corresponds to whether you've done it that particular day. I don't know if you know binary numbers, but the first 7 numbers are; 000 = 0, 001 = 1, 010 = 2, 011 = 3, 100 = 4, 101 = 5, 110 = 6 and 111 = 7. In our interpretation we'd store 7, aka 111, to indicate that we've done the habit the first three days of the month. If we didn't do it the second day we'd store 5, aka 101.
The actual setting/handling of the binary numbers can be easily done using bitwise operators, and this would mean that a given month could be stored in a single number. The only thing to decide then would be which of the following format would be most beneficial:
entries:
- 2024-02: 123098
- 2024-03: 65535
entries-2024-02: 123098
entries-2024-03: 65535
The main difference between these two is how they'll look natively with Obsidian:
Where the former is just going to be a data/json block, and the second variant will show the months and some seemingly random number after it.
Do this sound interesting? Do you want me to do a pull request implementing this? If so, which format would you like, and how do you suggest we tackle old data?
This takes me back to high school, when I learned bitwise operations. Thanks for that, I loved high school.
What I like about Obsidian and the philosophy that I had with HabitTracker21 was to have everything working even if you're using notepad. The information should be decrypted and easy to understand for anyone that stumbles upon these files. Because of this I think bit encoding, though a clever solution, but doesn't fit with my intent for this plugin.
Is your concern that the array will get super long? Or would you like to have a month view instead of daily view?
My concern is that if I track a habit, like my Daily walks, over a year (or more), then the entries would be very long without having any real significance into that habit note.
So my idea would potentially be to allow both styles, and/or possibly to convert between the two, as I do see that having a number like 12309123091238 would very clear convey which days in that month you've done the habit or not. But it sure is shorter than having whatever many entries.
As I think about it, maybe there is a third option. Have entries with a key like 2024-02, but have the values as an array, so it could read something like: [1, 2, 3, 4, ..., 31]. This could still cause less entries than the current solution. Yet another variant, to allow for easier manipulation would be to use 2024-01 as the key, and the day numbers as a list within that month.
This last variant would look like:
(Sadly it's still expanded into many lines in source mode, but it's still slightly better when viewing properties of the files with many full date entries)