| … | … | @@ -48,3 +48,53 @@ identification.) |
| 48 | 48 | Thus, it makes sense for the key to be the specific Atom, usually a |
| 49 | 49 | QueryLink, but also maybe any other atom that specifies the specific |
| 50 | 50 | vocabulary for the specific embedding. |
| 51 | |
| 52 | The base assumption here is that, during training, the embedding vector |
| 53 | will change; thus, we cannot have one global unique embedding vector per |
| 54 | Atom, as it is something that will be changing. Thus, it is part of the |
| 55 | specific model. |
| 56 | |
| 57 | ### Initial Embedding API |
| 58 | An initial embedding that is a deterministic function of the Atom hash |
| 59 | value seems entirely reasonable. What is the corret API for producing |
| 60 | this? It needs to have: |
| 61 | |
| 62 | * Length: 512, 768, 1024 or more elts. |
| 63 | * Type: FloatValue (for doubles), Float32Value, Float16Value, BoolValue |
| 64 | |
| 65 | The olde-school technique would be to write |
| 66 | ``` |
| 67 | (cog-execute! |
| 68 | (VectorEmbedLink |
| 69 | (Atom ...) |
| 70 | (NumberNode 768) |
| 71 | (TypeNode 'Float32Value))) |
| 72 | ``` |
| 73 | which would return the desired initial embedding. This works. Some |
| 74 | problems: |
| 75 | * Requires actually creating the Link. But this link is not really |
| 76 | needed for any kind of long-term use/re-use. |
| 77 | |
| 78 | A new-style OO API could be |
| 79 | ``` |
| 80 | (cog-set-value! |
| 81 | (EmbedNode "vector://Float32Value/768") |
| 82 | (Predicate "*-write-*) |
| 83 | (ListValue |
| 84 | (Atom ...) |
| 85 | (KeyWhereAtom ...) |
| 86 | (NumberNode 768) |
| 87 | (TypeNode 'Float32Value))) |
| 88 | ``` |
| 89 | But this is terrible, because the URL is ugly. |
| 90 | * Object URL's are supposed to represent external locations, but this |
| 91 | doesn't really need to be external. |
| 92 | * URL's imply the need for string manipulation, and the AtomSpace Node |
| 93 | API is not string oriented. |
| 94 | * Someday, Node names should be vectors, but that day has not yet arrived. |
| 95 | * There is no need for an open-close-read-write API, so having the OO |
| 96 | API does not seem to be needed. |
| 97 | * There's no reason to have a URL here, anyway... |
| 98 | |
| 99 | Overall: the OO API seems pointless and useless. |
| 100 | |