I'm going on vacation next week and it won't be possible for me to do
my review. I was just wondering if it would be possible to pause the
deck while I'm away, so that when I return I don't have an impossibly
large amount of cards to review?
I was under the assumption that suspending the cards did this but upon
testing it realized that I was wrong.
> I'm going on vacation next week and it won't be possible for me to do
> my review. I was just wondering if it would be possible to pause the
> deck while I'm away, so that when I return I don't have an impossibly
> large amount of cards to review?
> I was under the assumption that suspending the cards did this but upon
> testing it realized that I was wrong.
There is a Postpone plug-in that will allow you to spread your cards
out over a number of days you specify.
So if you come back and there's 700 cards waiting, you suspend those
over 7 days - giving you 100 cards per day (on top of that day's
normal reviews).
Not ideal, but it works well enough.
Essentially, though, you won't be doing any more or less work over
that one week period - but you will be able to whittle your deck down
to 0 cards each day, to give you a sense of accomplishment. :)
On Dec 13, 10:38 am, stevetsion <stevie_T...@hotmail.com> wrote:
> I'm going on vacation next week and it won't be possible for me to do
> my review. I was just wondering if it would be possible to pause the
> deck while I'm away, so that when I return I don't have an impossibly
> large amount of cards to review?
> I was under the assumption that suspending the cards did this but upon
> testing it realized that I was wrong.
On Sun, Dec 14, 2008 at 12:15 PM, Ben <nielson....@gmail.com> wrote:
> There is a Postpone plug-in that will allow you to spread your cards
> out over a number of days you specify.
> So if you come back and there's 700 cards waiting, you suspend those
> over 7 days - giving you 100 cards per day (on top of that day's
> normal reviews).
> Not ideal, but it works well enough.
> Essentially, though, you won't be doing any more or less work over
> that one week period - but you will be able to whittle your deck down
> to 0 cards each day, to give you a sense of accomplishment. :)
> On Dec 13, 10:38 am, stevetsion <stevie_T...@hotmail.com> wrote:
>> I'm going on vacation next week and it won't be possible for me to do
>> my review. I was just wondering if it would be possible to pause the
>> deck while I'm away, so that when I return I don't have an impossibly
>> large amount of cards to review?
>> I was under the assumption that suspending the cards did this but upon
>> testing it realized that I was wrong.
Yeah, coming back from vacation is a bitch :( What would be nice is
some sort of plugin where you specified your vacation dates, then it
would:
1) stop giving you new cards that you couldn't possibly get a review
period longer then your vacation period.
2) It would also show cards that would normally show up during your
vacation, before you left.
#2 would mean cards have a better spread when you come back. These
cards would need to be not just thrown at you on the last day, but due
to the absence of new cards (#1) it shouldn't result in any extra
work.
Actually, I'd say this is important enough functionality that if it
was coded, it should be merged in with the main code.
If I'd had this, I probably wouldn't of come back with 2000+ cards due
and made the switch to iKnow for vocab training.
Bodey
On Dec 14, 12:18 pm, "Damien Elmes" <resol...@gmail.com> wrote:
> We can't pause forgetting things, so Anki has no pause option either.
> The cards are due for review so that you don't forget them.
> On Sun, Dec 14, 2008 at 12:15 PM, Ben <nielson....@gmail.com> wrote:
> > There is a Postpone plug-in that will allow you to spread your cards
> > out over a number of days you specify.
> > So if you come back and there's 700 cards waiting, you suspend those
> > over 7 days - giving you 100 cards per day (on top of that day's
> > normal reviews).
> > Not ideal, but it works well enough.
> > Essentially, though, you won't be doing any more or less work over
> > that one week period - but you will be able to whittle your deck down
> > to 0 cards each day, to give you a sense of accomplishment. :)
> > On Dec 13, 10:38 am, stevetsion <stevie_T...@hotmail.com> wrote:
> >> I'm going on vacation next week and it won't be possible for me to do
> >> my review. I was just wondering if it would be possible to pause the
> >> deck while I'm away, so that when I return I don't have an impossibly
> >> large amount of cards to review?
> >> I was under the assumption that suspending the cards did this but upon
> >> testing it realized that I was wrong.
Ultimately the material needs to be studied. We can move it around and reschedule it back into the future to make it appear like the load has been reduced, but you'll still end up having to review the same number of cards.
> 1) stop giving you new cards that you couldn't possibly get a review > period longer then your vacation period.
If you know you're going on vacation, can't you do this yourself?
> 2) It would also show cards that would normally show up during your > vacation, before you left.
I'm reluctant to implement any sort of 'learn ahead of schedule' option, as it can be easily abused.
> If I'd had this, I probably wouldn't of come back with 2000+ cards due > and made the switch to iKnow for vocab training.
Since the problem seems to be a loss of motivation, rather than rescheduling anything, the best approach is probably simply to present the information to the user in a more positive sense. Instead of saying '2000 cards due', it could say 'hundreds'. Of course, Anki would still need to provide a way to show the exact number due somewhere, and no doubt you'd go look that up out of curiosity and we'd be back to square one.
> > 1) stop giving you new cards that you couldn't possibly get a review
> > period longer then your vacation period.
> If you know you're going on vacation, can't you do this yourself?
But the maths is hard :( Yeah, fair point... I'm just not very good at
timing it.
> > 2) It would also show cards that would normally show up during your
> > vacation, before you left.
> I'm reluctant to implement any sort of 'learn ahead of schedule'
> option, as it can be easily abused.
What did you have in mind here. The idea is, do some work now so that
you don't have a *huge* amount to do in one hit when you get back. If
something was seen early and remembered correctly, then what's wrong
with starting the current interval again + randomness associated with
that interval? Overall, you will have to do more work but it should
also mean less of a heap when you get back since they will be spread
out, with some cards that would of originally been in that heap
actually being scheduled in a few months or more.
On Dec 14, 2:46 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
> Ultimately the material needs to be studied. We can move it around and
> reschedule it back into the future to make it appear like the load has
> been reduced, but you'll still end up having to review the same number
> of cards.
> > 1) stop giving you new cards that you couldn't possibly get a review
> > period longer then your vacation period.
> If you know you're going on vacation, can't you do this yourself?
> > 2) It would also show cards that would normally show up during your
> > vacation, before you left.
> I'm reluctant to implement any sort of 'learn ahead of schedule'
> option, as it can be easily abused.
> > If I'd had this, I probably wouldn't of come back with 2000+ cards due
> > and made the switch to iKnow for vocab training.
> Since the problem seems to be a loss of motivation, rather than
> rescheduling anything, the best approach is probably simply to present
> the information to the user in a more positive sense. Instead of
> saying '2000 cards due', it could say 'hundreds'. Of course, Anki
> would still need to provide a way to show the exact number due
> somewhere, and no doubt you'd go look that up out of curiosity and
> we'd be back to square one.
Ok, sorry to bring this up again. I've follow some of those old
threads (sorry if I've missed an important one) and I also think the
idea of pausing your deck for later is a ridiculous idea. (I probably
didn't always so I might of may previous posts saying otherwise).
Anyway, I'm still obviously missing something so someone please set me
straight...
So, spaced learning (I believe) is based on the principle that you
forget things after a time but there is an optimal time to remind
yourself before you forget and overtime this spacing will get larger.
The optimal time depends on how much/well you want to remember at any
given time. In its extreme you remind yourself of something just
before you forget. With this in mind, if you know full well when you
are going to have a holiday, up to two months in advance, isn't it
stupid to ignore that information? Assuming that the spaces are set
for just before you forget, then there will be some items that you
will forget during that period and with perfect knowledge of
scheduling and how your brain works, which I'd like to ignore for now,
you can schedule around this. How, can be argued later the point is
that its suboptimal to ignore this information. The program also has
information (that it shows you in a little pretty graph) that
summarises your previous responses. This information could be used to
calculate the chance that you will get this card to an space interval
that will be long enough to cover your whole holiday. When this drops
below a given threshold it could warn you such that you mush change
the threshold or defer learning new cards until the holiday is over.
So, where is the gaping whole in my logic that I seem to be missing?
On Dec 14, 10:25 pm, Porco-esphino <BodeyBa...@gmail.com> wrote:
> > > 1) stop giving you new cards that you couldn't possibly get a review
> > > period longer then your vacation period.
> > If you know you're going on vacation, can't you do this yourself?
> But the maths is hard :( Yeah, fair point... I'm just not very good at
> timing it.
> > > 2) It would also show cards that would normally show up during your
> > > vacation, before you left.
> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> > option, as it can be easily abused.
> What did you have in mind here. The idea is, do some work now so that
> you don't have a *huge* amount to do in one hit when you get back. If
> something was seen early and remembered correctly, then what's wrong
> with starting the current interval again + randomness associated with
> that interval? Overall, you will have to do more work but it should
> also mean less of a heap when you get back since they will be spread
> out, with some cards that would of originally been in that heap
> actually being scheduled in a few months or more.
> On Dec 14, 2:46 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
> > Ultimately the material needs to be studied. We can move it around and
> > reschedule it back into the future to make it appear like the load has
> > been reduced, but you'll still end up having to review the same number
> > of cards.
> > > 1) stop giving you new cards that you couldn't possibly get a review
> > > period longer then your vacation period.
> > If you know you're going on vacation, can't you do this yourself?
> > > 2) It would also show cards that would normally show up during your
> > > vacation, before you left.
> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> > option, as it can be easily abused.
> > > If I'd had this, I probably wouldn't of come back with 2000+ cards due
> > > and made the switch to iKnow for vocab training.
> > Since the problem seems to be a loss of motivation, rather than
> > rescheduling anything, the best approach is probably simply to present
> > the information to the user in a more positive sense. Instead of
> > saying '2000 cards due', it could say 'hundreds'. Of course, Anki
> > would still need to provide a way to show the exact number due
> > somewhere, and no doubt you'd go look that up out of curiosity and
> > we'd be back to square one.
It's possible to schedule reviews ahead of time to avoid forgetting
things if you go away, but as I said before I'm afraid the ability to
do reviews in advance would be misused by all the people who don't
understand the concept of SRS and just want to study more. I won't
rule out such a feature in the future, but if Anki implements such a
feature, it should do it right, and that will require a fair amount of
thinking. It's not something for the near future.
On Fri, Dec 19, 2008 at 11:17 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
> Ok, sorry to bring this up again. I've follow some of those old
> threads (sorry if I've missed an important one) and I also think the
> idea of pausing your deck for later is a ridiculous idea. (I probably
> didn't always so I might of may previous posts saying otherwise).
> Anyway, I'm still obviously missing something so someone please set me
> straight...
> So, spaced learning (I believe) is based on the principle that you
> forget things after a time but there is an optimal time to remind
> yourself before you forget and overtime this spacing will get larger.
> The optimal time depends on how much/well you want to remember at any
> given time. In its extreme you remind yourself of something just
> before you forget. With this in mind, if you know full well when you
> are going to have a holiday, up to two months in advance, isn't it
> stupid to ignore that information? Assuming that the spaces are set
> for just before you forget, then there will be some items that you
> will forget during that period and with perfect knowledge of
> scheduling and how your brain works, which I'd like to ignore for now,
> you can schedule around this. How, can be argued later the point is
> that its suboptimal to ignore this information. The program also has
> information (that it shows you in a little pretty graph) that
> summarises your previous responses. This information could be used to
> calculate the chance that you will get this card to an space interval
> that will be long enough to cover your whole holiday. When this drops
> below a given threshold it could warn you such that you mush change
> the threshold or defer learning new cards until the holiday is over.
> So, where is the gaping whole in my logic that I seem to be missing?
> On Dec 14, 10:25 pm, Porco-esphino <BodeyBa...@gmail.com> wrote:
>> > > 1) stop giving you new cards that you couldn't possibly get a review
>> > > period longer then your vacation period.
>> > If you know you're going on vacation, can't you do this yourself?
>> But the maths is hard :( Yeah, fair point... I'm just not very good at
>> timing it.
>> > > 2) It would also show cards that would normally show up during your
>> > > vacation, before you left.
>> > I'm reluctant to implement any sort of 'learn ahead of schedule'
>> > option, as it can be easily abused.
>> What did you have in mind here. The idea is, do some work now so that
>> you don't have a *huge* amount to do in one hit when you get back. If
>> something was seen early and remembered correctly, then what's wrong
>> with starting the current interval again + randomness associated with
>> that interval? Overall, you will have to do more work but it should
>> also mean less of a heap when you get back since they will be spread
>> out, with some cards that would of originally been in that heap
>> actually being scheduled in a few months or more.
>> On Dec 14, 2:46 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
>> > Ultimately the material needs to be studied. We can move it around and
>> > reschedule it back into the future to make it appear like the load has
>> > been reduced, but you'll still end up having to review the same number
>> > of cards.
>> > > 1) stop giving you new cards that you couldn't possibly get a review
>> > > period longer then your vacation period.
>> > If you know you're going on vacation, can't you do this yourself?
>> > > 2) It would also show cards that would normally show up during your
>> > > vacation, before you left.
>> > I'm reluctant to implement any sort of 'learn ahead of schedule'
>> > option, as it can be easily abused.
>> > > If I'd had this, I probably wouldn't of come back with 2000+ cards due
>> > > and made the switch to iKnow for vocab training.
>> > Since the problem seems to be a loss of motivation, rather than
>> > rescheduling anything, the best approach is probably simply to present
>> > the information to the user in a more positive sense. Instead of
>> > saying '2000 cards due', it could say 'hundreds'. Of course, Anki
>> > would still need to provide a way to show the exact number due
>> > somewhere, and no doubt you'd go look that up out of curiosity and
>> > we'd be back to square one.
Far enough. Well I'd like to put forward what I fleshed out a few
nights ago when I couldn't sleep. There are more important things on
your plate right now so I don't expect you to implement it, but if you
do like some of the ideas and are interested in something for the
future, let me know. If you don't then could you let me know if its
possible to implement as a plugin and how long you think it might
take. And, anything that is stupid or abusable :)
So, first the user puts in the start and end date of there holiday.
Obviously, the earlier a user can put in this date the better. The
user also specifies a threshold for the chance of a new card not being
able to be scheduled across the holiday before its holiday time.
At this point some sort of rescheduling Algorithm should probably be
run (which is sadly open to abuse).
From then, anytime a card is answered it is tested to see if it falls
in this range. If it is then it is rescheduled.
While a holiday is scheduled, before a new card is shown the chance of
the card being answered such that it can be scheduled across the
holiday is tested. If its less the a threshold then a dialogue pops up
with the option to postpone all new cards until the end of the
holiday, or to change the threshold.
I think the above is fairly sound, feel free to prove me wrong
though :)
It then comes down to rescheduling. My idea is to simply reschedule
the card for a random time between now and the start of the holiday
while keeping the ease factor and current interval the same. I think
this is not optimal, but will ensure that you don't forget a card and
mean that you wont end up with a pile at the end of your holiday. It
should also mean that any attempt at abuse would just lead to cards
not changing which isn't optimal but removes incentive to set holidays
too frequently.
At some point it might be nice to put in multiple dates so maybe for
extensibility reasons the way to put in a date would be in ascii with
the range separated by '-' and different holidays delimited with ';'.
Maybe anything after the first ';' would be ignored for the alpha and
beta stages since it would complicate testing.
So... foolish?
On Dec 20, 2:55 am, "Damien Elmes" <reso...@ichi2.net> wrote:
> It's possible to schedule reviews ahead of time to avoid forgetting
> things if you go away, but as I said before I'm afraid the ability to
> do reviews in advance would be misused by all the people who don't
> understand the concept of SRS and just want to study more. I won't
> rule out such a feature in the future, but if Anki implements such a
> feature, it should do it right, and that will require a fair amount of
> thinking. It's not something for the near future.
> On Fri, Dec 19, 2008 at 11:17 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
> > Ok, sorry to bring this up again. I've follow some of those old
> > threads (sorry if I've missed an important one) and I also think the
> > idea of pausing your deck for later is a ridiculous idea. (I probably
> > didn't always so I might of may previous posts saying otherwise).
> > Anyway, I'm still obviously missing something so someone please set me
> > straight...
> > So, spaced learning (I believe) is based on the principle that you
> > forget things after a time but there is an optimal time to remind
> > yourself before you forget and overtime this spacing will get larger.
> > The optimal time depends on how much/well you want to remember at any
> > given time. In its extreme you remind yourself of something just
> > before you forget. With this in mind, if you know full well when you
> > are going to have a holiday, up to two months in advance, isn't it
> > stupid to ignore that information? Assuming that the spaces are set
> > for just before you forget, then there will be some items that you
> > will forget during that period and with perfect knowledge of
> > scheduling and how your brain works, which I'd like to ignore for now,
> > you can schedule around this. How, can be argued later the point is
> > that its suboptimal to ignore this information. The program also has
> > information (that it shows you in a little pretty graph) that
> > summarises your previous responses. This information could be used to
> > calculate the chance that you will get this card to an space interval
> > that will be long enough to cover your whole holiday. When this drops
> > below a given threshold it could warn you such that you mush change
> > the threshold or defer learning new cards until the holiday is over.
> > So, where is the gaping whole in my logic that I seem to be missing?
> > On Dec 14, 10:25 pm, Porco-esphino <BodeyBa...@gmail.com> wrote:
> >> > > 1) stop giving you new cards that you couldn't possibly get a review
> >> > > period longer then your vacation period.
> >> > If you know you're going on vacation, can't you do this yourself?
> >> But the maths is hard :( Yeah, fair point... I'm just not very good at
> >> timing it.
> >> > > 2) It would also show cards that would normally show up during your
> >> > > vacation, before you left.
> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> >> > option, as it can be easily abused.
> >> What did you have in mind here. The idea is, do some work now so that
> >> you don't have a *huge* amount to do in one hit when you get back. If
> >> something was seen early and remembered correctly, then what's wrong
> >> with starting the current interval again + randomness associated with
> >> that interval? Overall, you will have to do more work but it should
> >> also mean less of a heap when you get back since they will be spread
> >> out, with some cards that would of originally been in that heap
> >> actually being scheduled in a few months or more.
> >> On Dec 14, 2:46 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
> >> > Ultimately the material needs to be studied. We can move it around and
> >> > reschedule it back into the future to make it appear like the load has
> >> > been reduced, but you'll still end up having to review the same number
> >> > of cards.
> >> > > 1) stop giving you new cards that you couldn't possibly get a review
> >> > > period longer then your vacation period.
> >> > If you know you're going on vacation, can't you do this yourself?
> >> > > 2) It would also show cards that would normally show up during your
> >> > > vacation, before you left.
> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> >> > option, as it can be easily abused.
> >> > > If I'd had this, I probably wouldn't of come back with 2000+ cards due
> >> > > and made the switch to iKnow for vocab training.
> >> > Since the problem seems to be a loss of motivation, rather than
> >> > rescheduling anything, the best approach is probably simply to present
> >> > the information to the user in a more positive sense. Instead of
> >> > saying '2000 cards due', it could say 'hundreds'. Of course, Anki
> >> > would still need to provide a way to show the exact number due
> >> > somewhere, and no doubt you'd go look that up out of curiosity and
> >> > we'd be back to square one.
It sounds too complex. The best solution is usually the simplest one.
Anyway, 'postpone' has been available as a plugin for quite some time
- such prescheduling could easily be done in a plugin too. There's no
need to wait. And plugins that demonstrate their usefulness stand a
chance of inclusion into Anki in the future. :-)
On Sun, Dec 21, 2008 at 8:52 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
> Far enough. Well I'd like to put forward what I fleshed out a few
> nights ago when I couldn't sleep. There are more important things on
> your plate right now so I don't expect you to implement it, but if you
> do like some of the ideas and are interested in something for the
> future, let me know. If you don't then could you let me know if its
> possible to implement as a plugin and how long you think it might
> take. And, anything that is stupid or abusable :)
> So, first the user puts in the start and end date of there holiday.
> Obviously, the earlier a user can put in this date the better. The
> user also specifies a threshold for the chance of a new card not being
> able to be scheduled across the holiday before its holiday time.
> At this point some sort of rescheduling Algorithm should probably be
> run (which is sadly open to abuse).
> From then, anytime a card is answered it is tested to see if it falls
> in this range. If it is then it is rescheduled.
> While a holiday is scheduled, before a new card is shown the chance of
> the card being answered such that it can be scheduled across the
> holiday is tested. If its less the a threshold then a dialogue pops up
> with the option to postpone all new cards until the end of the
> holiday, or to change the threshold.
> I think the above is fairly sound, feel free to prove me wrong
> though :)
> It then comes down to rescheduling. My idea is to simply reschedule
> the card for a random time between now and the start of the holiday
> while keeping the ease factor and current interval the same. I think
> this is not optimal, but will ensure that you don't forget a card and
> mean that you wont end up with a pile at the end of your holiday. It
> should also mean that any attempt at abuse would just lead to cards
> not changing which isn't optimal but removes incentive to set holidays
> too frequently.
> At some point it might be nice to put in multiple dates so maybe for
> extensibility reasons the way to put in a date would be in ascii with
> the range separated by '-' and different holidays delimited with ';'.
> Maybe anything after the first ';' would be ignored for the alpha and
> beta stages since it would complicate testing.
> So... foolish?
> On Dec 20, 2:55 am, "Damien Elmes" <reso...@ichi2.net> wrote:
>> It's possible to schedule reviews ahead of time to avoid forgetting
>> things if you go away, but as I said before I'm afraid the ability to
>> do reviews in advance would be misused by all the people who don't
>> understand the concept of SRS and just want to study more. I won't
>> rule out such a feature in the future, but if Anki implements such a
>> feature, it should do it right, and that will require a fair amount of
>> thinking. It's not something for the near future.
>> On Fri, Dec 19, 2008 at 11:17 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
>> > Ok, sorry to bring this up again. I've follow some of those old
>> > threads (sorry if I've missed an important one) and I also think the
>> > idea of pausing your deck for later is a ridiculous idea. (I probably
>> > didn't always so I might of may previous posts saying otherwise).
>> > Anyway, I'm still obviously missing something so someone please set me
>> > straight...
>> > So, spaced learning (I believe) is based on the principle that you
>> > forget things after a time but there is an optimal time to remind
>> > yourself before you forget and overtime this spacing will get larger.
>> > The optimal time depends on how much/well you want to remember at any
>> > given time. In its extreme you remind yourself of something just
>> > before you forget. With this in mind, if you know full well when you
>> > are going to have a holiday, up to two months in advance, isn't it
>> > stupid to ignore that information? Assuming that the spaces are set
>> > for just before you forget, then there will be some items that you
>> > will forget during that period and with perfect knowledge of
>> > scheduling and how your brain works, which I'd like to ignore for now,
>> > you can schedule around this. How, can be argued later the point is
>> > that its suboptimal to ignore this information. The program also has
>> > information (that it shows you in a little pretty graph) that
>> > summarises your previous responses. This information could be used to
>> > calculate the chance that you will get this card to an space interval
>> > that will be long enough to cover your whole holiday. When this drops
>> > below a given threshold it could warn you such that you mush change
>> > the threshold or defer learning new cards until the holiday is over.
>> > So, where is the gaping whole in my logic that I seem to be missing?
>> > On Dec 14, 10:25 pm, Porco-esphino <BodeyBa...@gmail.com> wrote:
>> >> > > 1) stop giving you new cards that you couldn't possibly get a review
>> >> > > period longer then your vacation period.
>> >> > If you know you're going on vacation, can't you do this yourself?
>> >> But the maths is hard :( Yeah, fair point... I'm just not very good at
>> >> timing it.
>> >> > > 2) It would also show cards that would normally show up during your
>> >> > > vacation, before you left.
>> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
>> >> > option, as it can be easily abused.
>> >> What did you have in mind here. The idea is, do some work now so that
>> >> you don't have a *huge* amount to do in one hit when you get back. If
>> >> something was seen early and remembered correctly, then what's wrong
>> >> with starting the current interval again + randomness associated with
>> >> that interval? Overall, you will have to do more work but it should
>> >> also mean less of a heap when you get back since they will be spread
>> >> out, with some cards that would of originally been in that heap
>> >> actually being scheduled in a few months or more.
>> >> On Dec 14, 2:46 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
>> >> > Ultimately the material needs to be studied. We can move it around and
>> >> > reschedule it back into the future to make it appear like the load has
>> >> > been reduced, but you'll still end up having to review the same number
>> >> > of cards.
>> >> > > 1) stop giving you new cards that you couldn't possibly get a review
>> >> > > period longer then your vacation period.
>> >> > If you know you're going on vacation, can't you do this yourself?
>> >> > > 2) It would also show cards that would normally show up during your
>> >> > > vacation, before you left.
>> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
>> >> > option, as it can be easily abused.
>> >> > > If I'd had this, I probably wouldn't of come back with 2000+ cards due
>> >> > > and made the switch to iKnow for vocab training.
>> >> > Since the problem seems to be a loss of motivation, rather than
>> >> > rescheduling anything, the best approach is probably simply to present
>> >> > the information to the user in a more positive sense. Instead of
>> >> > saying '2000 cards due', it could say 'hundreds'. Of course, Anki
>> >> > would still need to provide a way to show the exact number due
>> >> > somewhere, and no doubt you'd go look that up out of curiosity and
>> >> > we'd be back to square one.
Okay, I'll play when I have some free time. I just haven't looked into
what a plugin can do and I wasn't sure if it was possible (to do as a
plugin).
But too complex? really? All it is really is:
- don't take a new card if its probably going to be in the pile at
the end of the holiday
- reschedule most of the cards that are being scheduled into the
holiday period.
It makes sense to schedule them before the holiday and let the current
scheduler take care of the rest.
How is that complicated?
The postpone add on is too simple. Your brain doesn't stop forgetting.
You may as well just go through the pile slowly..
On Dec 22, 11:05 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
> It sounds too complex. The best solution is usually the simplest one.
> Anyway, 'postpone' has been available as a plugin for quite some time
> - such prescheduling could easily be done in a plugin too. There's no
> need to wait. And plugins that demonstrate their usefulness stand a
> chance of inclusion into Anki in the future. :-)
> On Sun, Dec 21, 2008 at 8:52 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
> > Far enough. Well I'd like to put forward what I fleshed out a few
> > nights ago when I couldn't sleep. There are more important things on
> > your plate right now so I don't expect you to implement it, but if you
> > do like some of the ideas and are interested in something for the
> > future, let me know. If you don't then could you let me know if its
> > possible to implement as a plugin and how long you think it might
> > take. And, anything that is stupid or abusable :)
> > So, first the user puts in the start and end date of there holiday.
> > Obviously, the earlier a user can put in this date the better. The
> > user also specifies a threshold for the chance of a new card not being
> > able to be scheduled across the holiday before its holiday time.
> > At this point some sort of rescheduling Algorithm should probably be
> > run (which is sadly open to abuse).
> > From then, anytime a card is answered it is tested to see if it falls
> > in this range. If it is then it is rescheduled.
> > While a holiday is scheduled, before a new card is shown the chance of
> > the card being answered such that it can be scheduled across the
> > holiday is tested. If its less the a threshold then a dialogue pops up
> > with the option to postpone all new cards until the end of the
> > holiday, or to change the threshold.
> > I think the above is fairly sound, feel free to prove me wrong
> > though :)
> > It then comes down to rescheduling. My idea is to simply reschedule
> > the card for a random time between now and the start of the holiday
> > while keeping the ease factor and current interval the same. I think
> > this is not optimal, but will ensure that you don't forget a card and
> > mean that you wont end up with a pile at the end of your holiday. It
> > should also mean that any attempt at abuse would just lead to cards
> > not changing which isn't optimal but removes incentive to set holidays
> > too frequently.
> > At some point it might be nice to put in multiple dates so maybe for
> > extensibility reasons the way to put in a date would be in ascii with
> > the range separated by '-' and different holidays delimited with ';'.
> > Maybe anything after the first ';' would be ignored for the alpha and
> > beta stages since it would complicate testing.
> > So... foolish?
> > On Dec 20, 2:55 am, "Damien Elmes" <reso...@ichi2.net> wrote:
> >> It's possible to schedule reviews ahead of time to avoid forgetting
> >> things if you go away, but as I said before I'm afraid the ability to
> >> do reviews in advance would be misused by all the people who don't
> >> understand the concept of SRS and just want to study more. I won't
> >> rule out such a feature in the future, but if Anki implements such a
> >> feature, it should do it right, and that will require a fair amount of
> >> thinking. It's not something for the near future.
> >> On Fri, Dec 19, 2008 at 11:17 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
> >> > Ok, sorry to bring this up again. I've follow some of those old
> >> > threads (sorry if I've missed an important one) and I also think the
> >> > idea of pausing your deck for later is a ridiculous idea. (I probably
> >> > didn't always so I might of may previous posts saying otherwise).
> >> > Anyway, I'm still obviously missing something so someone please set me
> >> > straight...
> >> > So, spaced learning (I believe) is based on the principle that you
> >> > forget things after a time but there is an optimal time to remind
> >> > yourself before you forget and overtime this spacing will get larger.
> >> > The optimal time depends on how much/well you want to remember at any
> >> > given time. In its extreme you remind yourself of something just
> >> > before you forget. With this in mind, if you know full well when you
> >> > are going to have a holiday, up to two months in advance, isn't it
> >> > stupid to ignore that information? Assuming that the spaces are set
> >> > for just before you forget, then there will be some items that you
> >> > will forget during that period and with perfect knowledge of
> >> > scheduling and how your brain works, which I'd like to ignore for now,
> >> > you can schedule around this. How, can be argued later the point is
> >> > that its suboptimal to ignore this information. The program also has
> >> > information (that it shows you in a little pretty graph) that
> >> > summarises your previous responses. This information could be used to
> >> > calculate the chance that you will get this card to an space interval
> >> > that will be long enough to cover your whole holiday. When this drops
> >> > below a given threshold it could warn you such that you mush change
> >> > the threshold or defer learning new cards until the holiday is over.
> >> > So, where is the gaping whole in my logic that I seem to be missing?
> >> > On Dec 14, 10:25 pm, Porco-esphino <BodeyBa...@gmail.com> wrote:
> >> >> > > 1) stop giving you new cards that you couldn't possibly get a review
> >> >> > > period longer then your vacation period.
> >> >> > If you know you're going on vacation, can't you do this yourself?
> >> >> But the maths is hard :( Yeah, fair point... I'm just not very good at
> >> >> timing it.
> >> >> > > 2) It would also show cards that would normally show up during your
> >> >> > > vacation, before you left.
> >> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> >> >> > option, as it can be easily abused.
> >> >> What did you have in mind here. The idea is, do some work now so that
> >> >> you don't have a *huge* amount to do in one hit when you get back. If
> >> >> something was seen early and remembered correctly, then what's wrong
> >> >> with starting the current interval again + randomness associated with
> >> >> that interval? Overall, you will have to do more work but it should
> >> >> also mean less of a heap when you get back since they will be spread
> >> >> out, with some cards that would of originally been in that heap
> >> >> actually being scheduled in a few months or more.
> >> >> On Dec 14, 2:46 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
> >> >> > Ultimately the material needs to be studied. We can move it around and
> >> >> > reschedule it back into the future to make it appear like the load has
> >> >> > been reduced, but you'll still end up having to review the same number
> >> >> > of cards.
> >> >> > > 1) stop giving you new cards that you couldn't possibly get a review
> >> >> > > period longer then your vacation period.
> >> >> > If you know you're going on vacation, can't you do this yourself?
> >> >> > > 2) It would also show cards that would normally show up during your
> >> >> > > vacation, before you left.
> >> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> >> >> > option, as it can be easily abused.
> >> >> > > If I'd had this, I probably wouldn't of come back with 2000+ cards due
> >> >> > > and made the switch to iKnow for vocab training.
> >> >> > Since the problem seems to be a loss of motivation, rather than
> >> >> > rescheduling anything, the best approach is probably simply to present
> >> >> > the information to the user in a more positive sense. Instead of
> >> >> > saying '2000 cards due', it could say 'hundreds'. Of course, Anki
> >> >> > would still need to provide a way to show the exact number due
> >> >> > somewhere, and no doubt you'd go look that up out of curiosity and
> >> >> > we'd be back to square one.
> It sounds too complex. The best solution is usually the simplest one.
> Anyway, 'postpone' has been available as a plugin for quite some time
> - such prescheduling could easily be done in a plugin too. There's no
> need to wait. And plugins that demonstrate their usefulness stand a
> chance of inclusion into Anki in the future. :-)
> On Sun, Dec 21, 2008 at 8:52 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
> > Far enough. Well I'd like to put forward what I fleshed out a few
> > nights ago when I couldn't sleep. There are more important things on
> > your plate right now so I don't expect you to implement it, but if you
> > do like some of the ideas and are interested in something for the
> > future, let me know. If you don't then could you let me know if its
> > possible to implement as a plugin and how long you think it might
> > take. And, anything that is stupid or abusable :)
> > So, first the user puts in the start and end date of there holiday.
> > Obviously, the earlier a user can put in this date the better. The
> > user also specifies a threshold for the chance of a new card not being
> > able to be scheduled across the holiday before its holiday time.
> > At this point some sort of rescheduling Algorithm should probably be
> > run (which is sadly open to abuse).
> > From then, anytime a card is answered it is tested to see if it falls
> > in this range. If it is then it is rescheduled.
> > While a holiday is scheduled, before a new card is shown the chance of
> > the card being answered such that it can be scheduled across the
> > holiday is tested. If its less the a threshold then a dialogue pops up
> > with the option to postpone all new cards until the end of the
> > holiday, or to change the threshold.
> > I think the above is fairly sound, feel free to prove me wrong
> > though :)
> > It then comes down to rescheduling. My idea is to simply reschedule
> > the card for a random time between now and the start of the holiday
> > while keeping the ease factor and current interval the same. I think
> > this is not optimal, but will ensure that you don't forget a card and
> > mean that you wont end up with a pile at the end of your holiday. It
> > should also mean that any attempt at abuse would just lead to cards
> > not changing which isn't optimal but removes incentive to set holidays
> > too frequently.
> > At some point it might be nice to put in multiple dates so maybe for
> > extensibility reasons the way to put in a date would be in ascii with
> > the range separated by '-' and different holidays delimited with ';'.
> > Maybe anything after the first ';' would be ignored for the alpha and
> > beta stages since it would complicate testing.
> > So... foolish?
> > On Dec 20, 2:55 am, "Damien Elmes" <reso...@ichi2.net> wrote:
> >> It's possible to schedule reviews ahead of time to avoid forgetting
> >> things if you go away, but as I said before I'm afraid the ability to
> >> do reviews in advance would be misused by all the people who don't
> >> understand the concept of SRS and just want to study more. I won't
> >> rule out such a feature in the future, but if Anki implements such a
> >> feature, it should do it right, and that will require a fair amount of
> >> thinking. It's not something for the near future.
> >> On Fri, Dec 19, 2008 at 11:17 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
> >> > Ok, sorry to bring this up again. I've follow some of those old
> >> > threads (sorry if I've missed an important one) and I also think the
> >> > idea of pausing your deck for later is a ridiculous idea. (I probably
> >> > didn't always so I might of may previous posts saying otherwise).
> >> > Anyway, I'm still obviously missing something so someone please set me
> >> > straight...
> >> > So, spaced learning (I believe) is based on the principle that you
> >> > forget things after a time but there is an optimal time to remind
> >> > yourself before you forget and overtime this spacing will get larger.
> >> > The optimal time depends on how much/well you want to remember at any
> >> > given time. In its extreme you remind yourself of something just
> >> > before you forget. With this in mind, if you know full well when you
> >> > are going to have a holiday, up to two months in advance, isn't it
> >> > stupid to ignore that information? Assuming that the spaces are set
> >> > for just before you forget, then there will be some items that you
> >> > will forget during that period and with perfect knowledge of
> >> > scheduling and how your brain works, which I'd like to ignore for now,
> >> > you can schedule around this. How, can be argued later the point is
> >> > that its suboptimal to ignore this information. The program also has
> >> > information (that it shows you in a little pretty graph) that
> >> > summarises your previous responses. This information could be used to
> >> > calculate the chance that you will get this card to an space interval
> >> > that will be long enough to cover your whole holiday. When this drops
> >> > below a given threshold it could warn you such that you mush change
> >> > the threshold or defer learning new cards until the holiday is over.
> >> > So, where is the gaping whole in my logic that I seem to be missing?
> >> > On Dec 14, 10:25 pm, Porco-esphino <BodeyBa...@gmail.com> wrote:
> >> >> > > 1) stop giving you new cards that you couldn't possibly get a review
> >> >> > > period longer then your vacation period.
> >> >> > If you know you're going on vacation, can't you do this yourself?
> >> >> But the maths is hard :( Yeah, fair point... I'm just not very good at
> >> >> timing it.
> >> >> > > 2) It would also show cards that would normally show up during your
> >> >> > > vacation, before you left.
> >> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> >> >> > option, as it can be easily abused.
> >> >> What did you have in mind here. The idea is, do some work now so that
> >> >> you don't have a *huge* amount to do in one hit when you get back. If
> >> >> something was seen early and remembered correctly, then what's wrong
> >> >> with starting the current interval again + randomness associated with
> >> >> that interval? Overall, you will have to do more work but it should
> >> >> also mean less of a heap when you get back since they will be spread
> >> >> out, with some cards that would of originally been in that heap
> >> >> actually being scheduled in a few months or more.
> >> >> On Dec 14, 2:46 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
> >> >> > Ultimately the material needs to be studied. We can move it around and
> >> >> > reschedule it back into the future to make it appear like the load has
> >> >> > been reduced, but you'll still end up having to review the same number
> >> >> > of cards.
> >> >> > > 1) stop giving you new cards that you couldn't possibly get a review
> >> >> > > period longer then your vacation period.
> >> >> > If you know you're going on vacation, can't you do this yourself?
> >> >> > > 2) It would also show cards that would normally show up during your
> >> >> > > vacation, before you left.
> >> >> > I'm reluctant to implement any sort of 'learn ahead of schedule'
> >> >> > option, as it can be easily abused.
> >> >> > > If I'd had this, I probably wouldn't of come back with 2000+ cards due
> >> >> > > and made the switch to iKnow for vocab training.
> >> >> > Since the problem seems to be a loss of motivation, rather than
> >> >> > rescheduling anything, the best approach is probably simply to present
> >> >> > the information to the user in a more positive sense. Instead of
> >> >> > saying '2000 cards due', it could say 'hundreds'. Of course, Anki
> >> >> > would still need to provide a way to show the exact number due
> >> >> > somewhere, and no doubt you'd go look that up out of curiosity and
> >> >> > we'd be back to square one.
> Okay, I'll play when I have some free time. I just haven't looked into > what a plugin can do and I wasn't sure if it was possible (to do as a > plugin).
You can accomplish basically anything in a plugin
> But too complex? really? All it is really is:
> - don't take a new card if its probably going to be in the pile at > the end of the holiday > - reschedule most of the cards that are being scheduled into the > holiday period.
> It makes sense to schedule them before the holiday and let the current > scheduler take care of the rest.
> How is that complicated?
The reviewing code is highly optimized to require a minimum of queries to the database for each card, and all those queries make full use of indexes. Scanning other cards in a certain date range would make things a lot slower on small devices like the iphone. You're much better off moving any non-trivial calculations to a run on demand routine, instead of requiring they be run on each rep.
> > - don't take a new card if its probably going to be in the pile at
> > the end of the holiday
That could be done at startup... no problem there. It will just test
and if required stop new cards.
> - reschedule most of the cards that are being scheduled into the
> holiday period.
Is this too complicated?
After card has been answered, test if its scheduled in the holiday
period *and* its interval is larger then the holiday period. If so,
choose a random time between the now and the start of the holiday to
assign the card.
The problem with this is that you might get two quick jumps especially
if its an mature card just before the holiday. And since this kinda
rely's on plenty of the cards having an interval far larger then the
duration of the holiday it's a bit of a flaw. Ideally I want to set
the interval back to what it was before the card was answered. I have
no idea how to do that though and if my logic is flawed.
Is python lazy with its boolean expression computations? I'm presuming
so but am I wrong?
On Dec 28, 12:37 am, "Damien Elmes" <reso...@ichi2.net> wrote:
> > Okay, I'll play when I have some free time. I just haven't looked into
> > what a plugin can do and I wasn't sure if it was possible (to do as a
> > plugin).
> You can accomplish basically anything in a plugin
> > But too complex? really? All it is really is:
> > - don't take a new card if its probably going to be in the pile at
> > the end of the holiday
> > - reschedule most of the cards that are being scheduled into the
> > holiday period.
> > It makes sense to schedule them before the holiday and let the current
> > scheduler take care of the rest.
> > How is that complicated?
> The reviewing code is highly optimized to require a minimum of queries
> to the database for each card, and all those queries make full use of
> indexes. Scanning other cards in a certain date range would make
> things a lot slower on small devices like the iphone. You're much
> better off moving any non-trivial calculations to a run on demand
> routine, instead of requiring they be run on each rep.
The changes you propose are unlikely to make it into the base distribution of Anki, but don't sound terribly difficult to implement as a plugin.
> Is python lazy with its boolean expression computations? I'm presuming > so but am I wrong?
If you mean 'do boolean expressions short circuit?', then the answer is yes, though be aware that half the logic is in python and half the logic is in SQL.
> The changes you propose are unlikely to make it into the base
> distribution of Anki, but don't sound terribly difficult to implement
> as a plugin.
> > Is python lazy with its boolean expression computations? I'm presuming
> > so but am I wrong?
> If you mean 'do boolean expressions short circuit?', then the answer
> is yes, though be aware that half the logic is in python and half the
> logic is in SQL.
Ooh, plugins can do just about anything. This is all new to me.
And as far as making it into the base dist, that your call. But I'm
assuming we both agree that, if you have a two week holiday in two
months time, there is very little reason (besides implementation
difficulties) for you to have a big pile at the end of that holiday. I
think that scheduling things so that people don't forget things during
there holiday, and ensuring they don't have a huge demotivating pile
of cards when they come back is an important addition to the base
code, and I'm open to suggestions. When it comes don't to it, your
opinion here is more important then mine :P Anyone else opinions are
of course welcome too :) If I'm incorrect, could you let me know why.
And if I am correct, is the main problem with my proposal that it will
slow down the review code?
I've thought about it, and I agree that what I proposed polled too
frequently. Here are my alterations. Are they still too often?
The test for the if new cards should be stopped should be done every
time a deck is opened. If the calculations are too intensive (which I
doubt), then a the stopping date can be calculated when the vacation
is first inputed and the test would just be against that.
Instead of testing every card to see if it will end up in the vacation
period, periodically test if there are any cards in the vacation
period and reschedule them. I had assumed that this would provide less
information for the rescheduling but it looks like this is not the
case. I'd say that should be tested every time a deck is opened, but
this does depend on the rescheduling policy.
Then the rescheduling policy. I think its best to move cards to the
front of the holiday so that they wont be forgotten. I think its best
to utilise the different intervals each of those cards will have and
the randomness anki uses in setting a new interval. I think most of
that will need to be done *after* they have been answered again. ie.
just move them in front of the holiday and let the scheduler take care
of it. If you move cards due dates to just before your holiday, then
your just moving that big pile and its just as demotivating. If you
randomly move the cards due date to a date between now and the start
of the holiday then its abusable and might lead to a quick increase in
intervals which will lead to you forgetting. To get around this the
interval should probably be decreased somewhat. I figure the amount
isn't critical for now since this is a beta of sorts, and could be
played with until its of a reasonable quality to make it to the main
release.
So, what sounds good and what sounds bad? I know your busy and this
one's kinda long, so don't rush your reply.
Also, I have some coding questions.
At the moment I'm using your anki.hooks.wrap function to wrap
ankiqt.mw.loadDeck. I know that's not the optimal place, but it was
easy. If you didn't have any problems with a lot of this being done on
loading a deck, where would be a reasonable place? I also, kinda left
it in ankiqt and didn't nestle it further down so that it would only
run on larger devices... but am I mistaken there? It gets called twice
sometimes so I suppose I should nestle it further. Finally, the
function I wrote to tack on the end of loadDeck only takes 3 arguments
and drops self as the first argument. Is that ok? I'm only into my
second day of coding python, so please forgive me :P Oh, clipped code
follows:
> short circuit? I wasn't taught that terminology. Thanks :)
> On Dec 29, 9:03 pm, "Damien Elmes" <resol...@gmail.com> wrote:
> > > Is this too complicated?
> > The changes you propose are unlikely to make it into the base
> > distribution of Anki, but don't sound terribly difficult to implement
> > as a plugin.
> > > Is python lazy with its boolean expression computations? I'm presuming
> > > so but am I wrong?
> > If you mean 'do boolean expressions short circuit?', then the answer
> > is yes, though be aware that half the logic is in python and half the
> > logic is in SQL.
Hi,
On Dec 19, 6:55 pm, "Damien Elmes" <reso...@ichi2.net> wrote:
> It's possible to schedule reviews ahead of time to avoid forgetting
> things if you go away, but as I said before I'm afraid the ability to
> do reviews in advance would be misused by all the people who don't
> understand the concept of SRS and just want to study more. I won't
why is reviewing cards ahead of their 'due time' against the concept
of SRS?
There is always a probability to forget some information, and the
earlier I review it, the more probable it is that I will still
remember it, and the stronger it will be in my memory.
So, I may be 'wasting' a little time by not using the most efficient
(in terms of total time spent reviewing/learned cards) point in time
to review, and thus review too often, but if I have spare time in the
metro, it would definitely make sense to have a 'review some more'
option on the 'Congratulations, you have finished the deck for today'
page, which would lead me to reviewing e.g. the 10 cards that will be
due next, I think.
> and ensuring they don't have a huge demotivating pile > of cards when they come back is an important addition to the base > code, and I'm open to suggestions.
I'm not sure it's worth adding yet another feature to the core program. I'd rather make plugins easier to fetch and download in the future, so people can pick and mix what advanced features they want.
> And if I am correct, is the main problem with my proposal that it will > slow down the review code?
It adds complexity to the code and the interface. One has a cost for end users, one has a cost for my development.
> I've thought about it, and I agree that what I proposed polled too > frequently. Here are my alterations. Are they still too often?
It's up to you how you write your plugin - I have only once asked someone to do something differently in their plugin, and that was disabling the update check completely. However, if I were writing something like this, I'd make it a one time operation that you run a few days before your holiday, that moves the cards with smaller intervals before your holiday, and the cards with larger intervals after your holiday. Dynamically rescheduling cards and performing checks at startup sounds like way too much effort. Keep it simple.
> At the moment I'm using your anki.hooks.wrap function to wrap > ankiqt.mw.loadDeck. I know that's not the optimal place, but it was > easy. If you didn't have any problems with a lot of this being done on > loading a deck, where would be a reasonable place? I also, kinda left > it in ankiqt and didn't nestle it further down so that it would only > run on larger devices... but am I mistaken there? It gets called twice > sometimes so I suppose I should nestle it further.
If it works, then where you put it is really up to you. Anki does not have a list of specific places to hook into - you're free to choose whatever function you please (at the minor risk of the function going away in the future).
> Finally, the > function I wrote to tack on the end of loadDeck only takes 3 arguments > and drops self as the first argument. Is that ok?
I don't know what you're asking here. If you don't need self and you ignore it, and it works, then I see no problem.
> > Finally, the
> > function I wrote to tack on the end of loadDeck only takes 3 arguments
> > and drops self as the first argument. Is that ok?
> I don't know what you're asking here. If you don't need self and you
> ignore it, and it works, then I see no problem.
Ah, thinking about it now I don't even know why I was worrying. I was
imagining the original loadDeck trying to use self and getting a void
pointer. Stupid.
I had trouble overriding the code and getting a reference to self.
What should I have done. Here's that code again. Oh, and is the
protection from execuation as main really necessary? Without anki
loaded there is no deck to destroy so the only problem would be a few
error messages, right? I just copied it from one of the plugins, but I
don't get is logic.
> > and ensuring they don't have a huge demotivating pile
> > of cards when they come back is an important addition to the base
> > code, and I'm open to suggestions.
> I'm not sure it's worth adding yet another feature to the core
> program. I'd rather make plugins easier to fetch and download in the
> future, so people can pick and mix what advanced features they want.
> > And if I am correct, is the main problem with my proposal that it will
> > slow down the review code?
> It adds complexity to the code and the interface. One has a cost for
> end users, one has a cost for my development.
> > I've thought about it, and I agree that what I proposed polled too
> > frequently. Here are my alterations. Are they still too often?
> It's up to you how you write your plugin - I have only once asked
> someone to do something differently in their plugin, and that was
> disabling the update check completely. However, if I were writing
> something like this, I'd make it a one time operation that you run a
> few days before your holiday, that moves the cards with smaller
> intervals before your holiday, and the cards with larger intervals
> after your holiday. Dynamically rescheduling cards and performing
> checks at startup sounds like way too much effort. Keep it simple.
> > At the moment I'm using your anki.hooks.wrap function to wrap
> > ankiqt.mw.loadDeck. I know that's not the optimal place, but it was
> > easy. If you didn't have any problems with a lot of this being done on
> > loading a deck, where would be a reasonable place? I also, kinda left
> > it in ankiqt and didn't nestle it further down so that it would only
> > run on larger devices... but am I mistaken there? It gets called twice
> > sometimes so I suppose I should nestle it further.
> If it works, then where you put it is really up to you. Anki does not
> have a list of specific places to hook into - you're free to choose
> whatever function you please (at the minor risk of the function going
> away in the future).
> > Finally, the
> > function I wrote to tack on the end of loadDeck only takes 3 arguments
> > and drops self as the first argument. Is that ok?
> I don't know what you're asking here. If you don't need self and you
> ignore it, and it works, then I see no problem.
On Sun, Jan 4, 2009 at 1:26 PM, Porco-esphino <BodeyBa...@gmail.com> wrote:
>> > Finally, the
>> > function I wrote to tack on the end of loadDeck only takes 3 arguments
>> > and drops self as the first argument. Is that ok?
>> I don't know what you're asking here. If you don't need self and you
>> ignore it, and it works, then I see no problem.
> Ah, thinking about it now I don't even know why I was worrying. I was
> imagining the original loadDeck trying to use self and getting a void
> pointer. Stupid.
> I had trouble overriding the code and getting a reference to self.
> What should I have done. Here's that code again. Oh, and is the
> protection from execuation as main really necessary? Without anki
> loaded there is no deck to destroy so the only problem would be a few
> error messages, right? I just copied it from one of the plugins, but I
> don't get is logic.
> And thanks for the reply
> from ankiqt import mw
> from anki.hooks import wrap
> On Jan 4, 10:50 am, "Damien Elmes" <reso...@ichi2.net> wrote:
>> > and ensuring they don't have a huge demotivating pile
>> > of cards when they come back is an important addition to the base
>> > code, and I'm open to suggestions.
>> I'm not sure it's worth adding yet another feature to the core
>> program. I'd rather make plugins easier to fetch and download in the
>> future, so people can pick and mix what advanced features they want.
>> > And if I am correct, is the main problem with my proposal that it will
>> > slow down the review code?
>> It adds complexity to the code and the interface. One has a cost for
>> end users, one has a cost for my development.
>> > I've thought about it, and I agree that what I proposed polled too
>> > frequently. Here are my alterations. Are they still too often?
>> It's up to you how you write your plugin - I have only once asked
>> someone to do something differently in their plugin, and that was
>> disabling the update check completely. However, if I were writing
>> something like this, I'd make it a one time operation that you run a
>> few days before your holiday, that moves the cards with smaller
>> intervals before your holiday, and the cards with larger intervals
>> after your holiday. Dynamically rescheduling cards and performing
>> checks at startup sounds like way too much effort. Keep it simple.
>> > At the moment I'm using your anki.hooks.wrap function to wrap
>> > ankiqt.mw.loadDeck. I know that's not the optimal place, but it was
>> > easy. If you didn't have any problems with a lot of this being done on
>> > loading a deck, where would be a reasonable place? I also, kinda left
>> > it in ankiqt and didn't nestle it further down so that it would only
>> > run on larger devices... but am I mistaken there? It gets called twice
>> > sometimes so I suppose I should nestle it further.
>> If it works, then where you put it is really up to you. Anki does not
>> have a list of specific places to hook into - you're free to choose
>> whatever function you please (at the minor risk of the function going
>> away in the future).
>> > Finally, the
>> > function I wrote to tack on the end of loadDeck only takes 3 arguments
>> > and drops self as the first argument. Is that ok?
>> I don't know what you're asking here. If you don't need self and you
>> ignore it, and it works, then I see no problem.
> Dynamically rescheduling cards and performing
> checks at startup sounds like way too much effort.
Its a frustrating overhead for the user too. I think your right, the
user can always run it a few times if they're paranoid they won't have
time later.
The first thing I'll code though is something that will give the user
and indication of when its a good idea to stop adding new cards based
on the length of the holiday and the start date.
I was hoping to use the users past history to work out when is best.
But when I actually thought about the implementation I noticed that to
do it properly involves some crazy unnecessary maths. I think I'll
just stick to a simple linear piecewise approximation. hitting good
and hard 50/50, only hitting good, only hitting easy. If someone has
an idea to a wikipedia page for the real maths I could use I'm
interested in reading it. My stat's knowledge is pretty bad :(
On Jan 4, 10:50 am, "Damien Elmes" <reso...@ichi2.net> wrote:
> > and ensuring they don't have a huge demotivating pile
> > of cards when they come back is an important addition to the base
> > code, and I'm open to suggestions.
> I'm not sure it's worth adding yet another feature to the core
> program. I'd rather make plugins easier to fetch and download in the
> future, so people can pick and mix what advanced features they want.
> > And if I am correct, is the main problem with my proposal that it will
> > slow down the review code?
> It adds complexity to the code and the interface. One has a cost for
> end users, one has a cost for my development.
> > I've thought about it, and I agree that what I proposed polled too
> > frequently. Here are my alterations. Are they still too often?
> It's up to you how you write your plugin - I have only once asked
> someone to do something differently in their plugin, and that was
> disabling the update check completely. However, if I were writing
> something like this, I'd make it a one time operation that you run a
> few days before your holiday, that moves the cards with smaller
> intervals before your holiday, and the cards with larger intervals
> after your holiday. Dynamically rescheduling cards and performing
> checks at startup sounds like way too much effort. Keep it simple.
> > At the moment I'm using your anki.hooks.wrap function to wrap
> > ankiqt.mw.loadDeck. I know that's not the optimal place, but it was
> > easy. If you didn't have any problems with a lot of this being done on
> > loading a deck, where would be a reasonable place? I also, kinda left
> > it in ankiqt and didn't nestle it further down so that it would only
> > run on larger devices... but am I mistaken there? It gets called twice
> > sometimes so I suppose I should nestle it further.
> If it works, then where you put it is really up to you. Anki does not
> have a list of specific places to hook into - you're free to choose
> whatever function you please (at the minor risk of the function going
> away in the future).
> > Finally, the
> > function I wrote to tack on the end of loadDeck only takes 3 arguments
> > and drops self as the first argument. Is that ok?
> I don't know what you're asking here. If you don't need self and you
> ignore it, and it works, then I see no problem.
