If your inbox is as big as mine, you won’t be able to load all the text content into a prompt even with SotA cloud hosted models.
Instead you should give it tools to search over the mailbox for terms, labels, addresses, etc. so that the model can do fine grained filters based on the query, read the relevant emails it finds, then answer the question.
Thanks, yeah. I think strong prefiltering is pretty much always doable because, if nothing else, I usually know the time range of the relevant emails and probably the sender/recipient or some keywords, plus I know how to filter out a big chunk of the irrelevant emails (like mailing lists, etc.), so I'm hoping it's not actually that much data for each search. What I don't know is which models would be most suitable even in the case where I can fit the data.
As an example of the kind of query I'm interested in, I want a model that can tell me all the flights I took within a given time range (so that means it'd have to filter out cancellations). Or, for a given flight, the arrival and departure times and time zones (or the city and country so I can look up the time zone). Stuff like that. (Travel is just an example obviously, I have other topics to ask about.) It's not a terribly large number of emails to search through in each query, but the email structures are too heterogeneous across senders to write custom tooling for each case.
Would buy this in a heartbeat (pun intended) if it came with a heart rate monitor.
I had the first Pebble Time Round and it's my favorite smart watch I've ever owned, but these days the things I want from a watch are to tell the time and collect biometrics. Taking a step back in biometrics feels like a bummer. I also totally buy that it would increase the foot print in a way that would feel way less slim.
Same! I've already signed up for the Time 2 and super stoked for it, then I saw the announcement for the Round 2 and I was about to switch over until I noticed it didn't have a heart rate sensor. I know its sleek and elegant, but that slight bulk would be worth it in my opinion. And who knows, with the extra thickness they might've been able to squeeze in more battery to get it to the 30 days battery life cited for the Time 2.
Also unfortunate that it's missing the RGB backlight of the Time 2. I can think of a few good use cases for it, but if it's only on the Time 2 that means fewer apps would use it.
Yeah it would’ve been an instant buy for me if it did HR monitoring, even if it meant a thicker base. Now it’ll probably just be a fairly quick buy as my Apple Watch s7 can hardly last a day.
The PT2 is thicker than the PR2 and has the HR monitor (it also costs $25 more). If you have an AW, then you're already used to the rectangular form factor of the PT2.
I think it's as much about familiarity than anything else. I've programmed full time in Clojure for the last 6 years, and I find it just as easy to read than other languages I'm familiar with (JavaScript, Java) and way less easy to read than other languages like Haskell or OCaml that have their own syntax lineage. I'm sure if I spent an amount of time becoming familiar with them, I'd find them just as easy as I do Lisp.
There are certain things that languages can do that make syntax easier; for instance, Clojure's default constructs reduce a lot of parens compared to CL by using brackets [] and removing nesting. For instance
;; clojure
(defn sum-and-square [a b]
(let [sum (+ a b)]
(* sum sum)))
;; common lisp
(defun sum-and-squaer (a b)
(let ((sum (+ a b))
(* sum sum)))
This leads some people to assert (with other reasons too) that Clojure is not in fact a "lisp."
I'm not sure what you are trying to show? Code can be in one line? Okaaaaay...
I was trying to show that one can define local variables without adding another list level via let.
Like if one would/could write in Clojure:
(defn sum-and-square [a b &blah sum (+ a b)] (* sum sum))
Another Common Lisp example, we'll stick to your one liner format, using infix syntax via a reader macro:
(defun sum-and-square (a b) #I(sum=a+b,sum*sum))
Before you ask: what am I trying to show? This shows that Common Lisp syntax can be deeply extended by the user and that this is a standard feature of the language. Want a shorter infix notation without s-expressions? Why not...
Reader macros are global and stateful, this is one of the worst things about Common Lisp. Excellent feature, pity we're forever burdened with the implementation.
AFAICT after the first write, the inner promise is resolved and will return the same value it was resolved with even if subsequent writes are made. This is totally different than Go-like channels which can receive multiple writes, often handling buffering them until they are consumed.
Instead you should give it tools to search over the mailbox for terms, labels, addresses, etc. so that the model can do fine grained filters based on the query, read the relevant emails it finds, then answer the question.
reply