I do hope it is OK, posting this here:
context: I am interested in smart cd jumping for years, have written my own version starting some 15 ago, was ignorant of z until a few years back and took note of existence of further similar tools only very recently (totally my fault...) -- and only yesterday I finally "discovered" fre.
and after having looked at it I just wanted to give some feedback and acknowledge your README remark that fre has been the only published tool so far actually utilising the visit history rather than just using "frequency plus time stamp of last visit" as the 'established' tools do. I fully agree that your approach is preferable/better.
some questions/remarks:
your exponential decay model sure is viable. phrased in your symbols I have instead used the function w(x) = sum ((x_i - x_0)/(now - x_0))^p, i.e. a power law of elapsed time since some settable starttime (or rather: offset before "now"). having 2 parameters (x_0 and p) offers relevant flexibility to tune the shape I believe. since I have not tested against the single-parameter exponentia I can't say whether the perceived advantage is really relevant. but the above power law does at least include shapes like a "ramp" (for p=1) which cannot be represented by an exponential, not even roughly.
it is an interesting observation in your README that you do not need to store the full event history x_i but only to maintain current cumulative sum value and add current increment to that (if I understand correctly what you are doing). this should be attractive to the z/zoxide people since they could adopt that without changing their logfile format much. the scoring they use (or rather the limited information entering the scoring) really is not optimal and causes problems like those you have noted.
in contrast to fre, I instead have opted for actual logging of the full history of directory visits and so, indeed, my tool can change the scoring retrospectively (by changing x_0 (within the range of total logfile entries) and, more relevantly, p). it is cheap enough.
have you ever considered doing that in your tool as well? I find it is nice since the user then can not only decide his principal default preference for the free parameter(s) -- lambda in your case -- once before starting to use the tool but he can change that preference later on or even only transiently during a shell session to fit his current needs and be able to apply the new setting to the historically accumulated data. have you ever considered doing that in your tool as well?
finally, I have actually never used real time stamps (wall-clock time) but just log the sequence of cd events itself and use the event as "clock tick". so the actual scoring is simply done with w = sum_i (i/N)^p where N selects some number of 'recent' events (say 1000) defining the history/time window to consider and i runs from 1 to N, enumerating the events (and "event time") in that window. this means, the scoring does not change during vacancies/holidays or over night. have you ever considered doing something like that or do you feel wall-clock time is still preferable as the "time axis"? I think one can validly argue for both but my feeling is that invariant scoring for a given state of the database is preferable.
last not least: much success to your project
I do hope it is OK, posting this here:
context: I am interested in smart cd jumping for years, have written my own version starting some 15 ago, was ignorant of z until a few years back and took note of existence of further similar tools only very recently (totally my fault...) -- and only yesterday I finally "discovered"
fre.and after having looked at it I just wanted to give some feedback and acknowledge your README remark that
frehas been the only published tool so far actually utilising the visit history rather than just using "frequency plus time stamp of last visit" as the 'established' tools do. I fully agree that your approach is preferable/better.some questions/remarks:
your exponential decay model sure is viable. phrased in your symbols I have instead used the function w(x) = sum ((x_i - x_0)/(now - x_0))^p, i.e. a power law of elapsed time since some settable starttime (or rather: offset before "now"). having 2 parameters (x_0 and p) offers relevant flexibility to tune the shape I believe. since I have not tested against the single-parameter exponentia I can't say whether the perceived advantage is really relevant. but the above power law does at least include shapes like a "ramp" (for p=1) which cannot be represented by an exponential, not even roughly.
it is an interesting observation in your README that you do not need to store the full event history x_i but only to maintain current cumulative sum value and add current increment to that (if I understand correctly what you are doing). this should be attractive to the z/zoxide people since they could adopt that without changing their logfile format much. the scoring they use (or rather the limited information entering the scoring) really is not optimal and causes problems like those you have noted.
in contrast to
fre, I instead have opted for actual logging of the full history of directory visits and so, indeed, my tool can change the scoring retrospectively (by changing x_0 (within the range of total logfile entries) and, more relevantly, p). it is cheap enough.have you ever considered doing that in your tool as well? I find it is nice since the user then can not only decide his principal default preference for the free parameter(s) -- lambda in your case -- once before starting to use the tool but he can change that preference later on or even only transiently during a shell session to fit his current needs and be able to apply the new setting to the historically accumulated data. have you ever considered doing that in your tool as well?
finally, I have actually never used real time stamps (wall-clock time) but just log the sequence of cd events itself and use the event as "clock tick". so the actual scoring is simply done with w = sum_i (i/N)^p where N selects some number of 'recent' events (say 1000) defining the history/time window to consider and i runs from 1 to N, enumerating the events (and "event time") in that window. this means, the scoring does not change during vacancies/holidays or over night. have you ever considered doing something like that or do you feel wall-clock time is still preferable as the "time axis"? I think one can validly argue for both but my feeling is that invariant scoring for a given state of the database is preferable.
last not least: much success to your project