Just this past week I spoke with a local hackathon team who was working on giving consumers access to fair medical pricing by having users ask an LLM about their procedure, which would then cross reference with a pricing database. Simple idea but useful given the variance in procedure costs depending on provider/hospital.
I was hoping to see the same. As I understand this, it would lock the notes to obsidian only, instead of being somewhat agnostic to the note taker medium.
I specifically tried to make this mostly Obsidian-agnostic - the algorithm to generate these note codes is very simple and only requires the note's path relative to the vault.
Here's the whole algorithm in Python:
import hashlib
def hash_string(s):
h = hashlib.sha256(s.encode()).digest()
n = ((h[0] << 16) | (h[1] << 8) | h[2]) % (32**4)
a = '0123456789ABCDEFGHJKMNPQRSTVWXYZ'
r = ''.join(a[n // 32**(3-i) % 32] for i in range(4))
return f"{r[:2]}-{r[2:]}"
Plus, Obsidian kind of already has this functionality. You can give any note an alias, and all linking to that alias will instead link to the note. So if you're not worried about being agnostic, and unless if you want to mark every single note, I still don't see the point. And even then, even assuming that you do want every note with a code alias, you can just set it up on a template.
Or just YYMMDD, since there's typically not all that many things you create in one day, so you can just browse among the search hits and it'll be obvious which of the hits you had in mind.
This looks fine, but then if I rename the note, the code changes, invalidating all the hand-written notes links. So it feels unpractical. I would still prefer to encode the creation timestamp and put it in the title/filename/property. At least this would be fixed.
I'm too lazy to write full note titles in my paper journals. With this, I can instead write a 4-character code that I can quickly look up in my Obsidian vault.
Plus, the existing linking system allows you to link to a particular heading within an existing note.
From memory… you begin with typing [[ to start the incremental autocomplete on note filename, then when the desired one is top of the list, press # to select a section based on heading.
Nice post. I think about time... all the time haha. There's another source you might enjoy (Re: your NTP and synchronization question) from TigerBeetle: [Implementing Time](https://www.youtube.com/watch?v=QtNmGqWe73g)
I spent a bit of time reading up on the internals and had a question about a small design choice (I am new to DB internals, specifically as they relate to vector DBs).
I notice that in your core vector type (`HVector`), you choose to store the vector data as a `Vec<f64>`. Given what I have seen from most embedding endpoints, they return `f32`s. Is there a particular reason for picking `f64` vs `f32` here? Is the additional precision a way to avoid headaches down the line or is it something I am missing context for?
thanks for the question! we chose f64 as a default for now as just to cover all cases and we believed that basic vector operations would not be our bottleneck initially. As we optimize our HNSW implementation, we are going to add support for f32 and binary vectors and drop using Vec<f64/f32> and instead use [f64/f32; {num_dimensions}] to avoid unnecessary heap allocation!
I appreciate the reply! Yeah that sounds like the correct path forward is swapping out the type for some enum of numeric types you want to cover.
I'd be curious if there's some benefit to the runtime-memory utilization to baking in the precision of the vector if it's known at comptime/runtime. In my own usage of vector DBs I've only ever used a single-precision (f32), and often have a single, known dimension. But if Helix is aiming for something more general purpose, then it makes sense to offer the mixing of precision and dimension in the internals.
The benefit of baking in the dimension and size of individual elements (the precision) is the fact that the size will be known at compile time meaning it can be allocated on the stack instead of being heap allocated.
One other point of annoyance with the new UI is that the videos actually aren't aligned vertically.
I really dislike auto-play so I have always strategically rested my cursor in between the columns of video. Now, as I scroll, my cursor will end up within a column that is misaligned and start autoplay. The worst!
If you're using an adblocker, it's because YouTube video grid items have an [is-in-first-column] attribute which gives them extra margin-left, throwing off alignment when videos flow to fill in gaps created by promoted videos which were hidden.
It's kind of silly that they add these attributes to each nth item based on what they expect the grid width to be, when you can get the same layout without them (my YouTube extension mentioned elsewhere in this thread performs this style fix so grid items line up properly when videos and entire cross-cutting shelves are hidden and the rest flow to fill in the gaps), but I suppose they have no incentive to make the layout work when videos are being hidden or the grid is otherwise being modified externally to work in a way they didn't want.
