Beeminding bedtime, revisited: having trouble modeling it

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having trouble setting up the sort of goal I want. I know others are using bedtime goals – I’ve read the recent thread on that topic – and I’m hoping people will have suggestions for me? I want to leave a lot of flexibility, at least at first, since this is going to be a real, real hard one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m starting with a gentle approach; for now I’m mostly just trying to cut down on the nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer that I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset myself to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to work. The main problem I’m hitting right up front is, I can’t find a way to fix the goal line at a specific, flat value. I’m actually using a “custom” type goal and even there I don’t see a way to do it. (I can make it flat by dialing in a rate of change of 0, but it’s picking the value for the centerline based on my initial data, of course, and I don’t want that.) Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder? How? (2) If not, is there a better way to model this that preserves most of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

I don’t think there’s a way to implement your exact idea without using the
Beeminder API. You could have a script [0] that fires once a week and subtracts
3 from the total, which wouldn’t be too hard. The other downside is that I
believe Danny and Bethany plan to obsolete permanently flat roads eventually,
although your graph might be grandfathered-in. At the moment you should be able
to make your road flat – I don’t know why you’re having problems.

The standard approach would be to make a “Set a Limit” goal that increases by
three each week. Under this scheme you are trying to stay below a total that
increases by three hours every week rather than trying to stay below zero. It
would be mostly the same, but look slightly different. One actual
difference is that you get more leeway slowly rather than all at once. (The
total hours of leeway would be the same.)

You need a custom goal to make roads zero-width, I think.

Best,
Alec

[0]: Or an IFTTT recipe. You could tell IFTTT to send an email to Beeminder
once per week subtracting three from your total. As far as I can tell, you need
a Gmail account to do this.

On Sun, Aug 18, 2013 at 05:02:41PM -0400, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having trouble setting up the sort of goal I want. I know others are using bedtime goals – I’ve read the recent thread on that topic – and I’m hoping people will have suggestions for me? I want to leave a lot of flexibility, at least at first, since this is going to be a real, real hard one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m starting with a gentle approach; for now I’m mostly just trying to cut down on the nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer that I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset myself to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to work. The main problem I’m hitting right up front is, I can’t find a way to fix the goal line at a specific, flat value. I’m actually using a “custom” type goal and even there I don’t see a way to do it. (I can make it flat by dialing in a rate of change of 0, but it’s picking the value for the centerline based on my initial data, of course, and I don’t want that.) Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder? How? (2) If not, is there a better way to model this that preserves most of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

You received this message because you are subscribed to the Google Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send an email to akratics+unsubscribe@googlegroups.com.

Set your weekly rate to 80. That’s 11 every night x 7 nights, plus 3 extra
buffer hours. Then, just enter your bed time as your datapoint (e.g. 10:45,
or e.g. 13:45 for 1:45 am) You won’t have the full 3 hours to draw on
during the first week, but you’ll be collecting your buffer throughout that
time and can accumulate it over the week for later in the week.

On Sunday, August 18, 2013 5:02:41 PM UTC-4, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having
trouble setting up the sort of goal I want. I know others are using
bedtime goals – I’ve read the recent thread on that topic – and I’m
hoping people will have suggestions for me? I want to leave a lot of
flexibility, at least at first, since this is going to be a real, real hard
one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m starting
with a gentle approach; for now I’m mostly just trying to cut down on the
nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer that I
can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway for
nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number of
hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer on
the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset myself
to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to
work. The main problem I’m hitting right up front is, I can’t find a way
to fix the goal line at a specific, flat value. I’m actually using a
"custom" type goal and even there I don’t see a way to do it. (I can make
it flat by dialing in a rate of change of 0, but it’s picking the value for
the centerline based on my initial data, of course, and I don’t want that.)
Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder?
How? (2) If not, is there a better way to model this that preserves most
of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

Hey Alec and Essentiae,

Thanks for your suggestions. Both of you suggested, basically, a limit that increases by 3 weekly, and both of you pointed out exactly what’s wrong with that approach: I won’t have the full leeway at the start of the week. I would have no flexibility on the first night of the week, ever – if I slip by even a minute, I derail, whereas by the end of the week I (might) have lots of leeway. Not only is that arbitrary and sort of weird, but it’s a near-guarantee that I’ll fail.

Still open to suggestions, and still pondering it myself. There’s got to be a way to quantify this better.

Alec, to clarify: I should have said I was planning on resetting to 3 hours of buffer each week manually. I didn’t expect to automate that (although your IFTTT idea is temptingly clever and I might use it if I ever get this working). And I’m not having trouble getting the road flat, at least not initially, or giving it a width of 0 – I’m using a custom goal. What isn’t working is getting the road to stay at 0. Beeminder is setting it flat at -3, matching my first data point (which was supposed to represent my buffer for the week).

I’m trying an experiment where I leave today’s first data point at 0, and wait till tomorrow to add the “reset” data point of -3 for this week. I’m not sure if that will leave the line at 0 or not.

Any more ideas, anybody?

Thanks,
Matthias

On Aug 18, 2013, at 6:31 PM, Alec Brooks zab1000@gmail.com wrote:

I don’t think there’s a way to implement your exact idea without using the
Beeminder API. You could have a script [0] that fires once a week and subtracts
3 from the total, which wouldn’t be too hard. The other downside is that I
believe Danny and Bethany plan to obsolete permanently flat roads eventually,
although your graph might be grandfathered-in. At the moment you should be able
to make your road flat – I don’t know why you’re having problems.

The standard approach would be to make a “Set a Limit” goal that increases by
three each week. Under this scheme you are trying to stay below a total that
increases by three hours every week rather than trying to stay below zero. It
would be mostly the same, but look slightly different. One actual
difference is that you get more leeway slowly rather than all at once. (The
total hours of leeway would be the same.)

You need a custom goal to make roads zero-width, I think.

Best,
Alec

[0]: Or an IFTTT recipe. You could tell IFTTT to send an email to Beeminder
once per week subtracting three from your total. As far as I can tell, you need
a Gmail account to do this.

On Sun, Aug 18, 2013 at 05:02:41PM -0400, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having trouble setting up the sort of goal I want. I know others are using bedtime goals – I’ve read the recent thread on that topic – and I’m hoping people will have suggestions for me? I want to leave a lot of flexibility, at least at first, since this is going to be a real, real hard one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m starting with a gentle approach; for now I’m mostly just trying to cut down on the nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer that I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset myself to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to work. The main problem I’m hitting right up front is, I can’t find a way to fix the goal line at a specific, flat value. I’m actually using a “custom” type goal and even there I don’t see a way to do it. (I can make it flat by dialing in a rate of change of 0, but it’s picking the value for the centerline based on my initial data, of course, and I don’t want that.) Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder? How? (2) If not, is there a better way to model this that preserves most of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

You received this message because you are subscribed to the Google Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send an email to akratics+unsubscribe@googlegroups.com.

You received this message because you are subscribed to the Google Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send an email to akratics+unsubscribe@googlegroups.com.

Hi Matthias,

Yes, I’ve implemented a similar goal to experiment with custom goals, so it
is possible (didn’t try zero road width though). However, it worked badly
and I would not advise using it. Why do you want to use such a system?
There may be alternative strategies to account for special behaviours or
needs.

It seems clunky and less intuitive to me than using the system Essentiae
suggests (again similar to my own).

In spite of the e-mail reminders, there is less incentive to report with a
flat line rather than a moving limit, including pessimistic presumptive
reporting for set-a-limit goals. I don’t use PPR for my sleep goal though,
because the double-rate penalty seems a bit scary for me when I’m skating
near the edge (like today) and as I am pretty compulsive about keeping my
data current.

One of the great strengths of Beeminder is documenting a continuous habit,
so in my opinion, resetting every week doesn’t gel as well with the mindset
of establishing uniform routines over long periods of time. For sleep,
aiming for consistency and low variability is really important. It is also
easier to see interesting trends with the normal set-a-limit goals over
weeks, which are somewhat arbitrary divisions anyway. I should confess that
I do use some rules that Danny probably wouldn’t like, such as halving
values when I’m out on a Friday night, but they are fairly consistent and
planned.

More generally, when I first set up my sleep goal, I set an alarm to remind
me to turn off my computer (or at least social media/phone/distracting
websites) and try to go to bed. Remaining mindful of the habit becomes more
natural with time (I don’t need alarms anymore), but just remembering to
check the time is not always easy. I then added a physical calendar that
lives at my bed to ensure that I record the data, also without playing with
the computer or phone seconds before bed, as all that light makes it harder
to sleep.

Apologies for the rambling. I’m a little sleep deprived.

Cheers,

Julian

On Monday, August 19, 2013 10:16:09 AM UTC+10, Matthias Ferber wrote:

Hey Alec and Essentiae,

Thanks for your suggestions. Both of you suggested, basically, a limit
that increases by 3 weekly, and both of you pointed out exactly what’s
wrong with that approach: I won’t have the full leeway at the start of the
week. I would have no flexibility on the first night of the week, ever –
if I slip by even a minute, I derail, whereas by the end of the week I
(might) have lots of leeway. Not only is that arbitrary and sort of weird,
but it’s a near-guarantee that I’ll fail.

Still open to suggestions, and still pondering it myself. There’s got to
be a way to quantify this better.

Alec, to clarify: I should have said I was planning on resetting to 3
hours of buffer each week manually. I didn’t expect to automate that
(although your IFTTT idea is temptingly clever and I might use it if I ever
get this working). And I’m not having trouble getting the road flat, at
least not initially, or giving it a width of 0 – I’m using a custom goal.
What isn’t working is getting the road to stay at 0. Beeminder is setting
it flat at -3, matching my first data point (which was supposed to
represent my buffer for the week).

I’m trying an experiment where I leave today’s first data point at 0, and
wait till tomorrow to add the “reset” data point of -3 for this week. I’m
not sure if that will leave the line at 0 or not.

Any more ideas, anybody?

Thanks,
Matthias

On Aug 18, 2013, at 6:31 PM, Alec Brooks <zab...@gmail.com <javascript:>>
wrote:

I don’t think there’s a way to implement your exact idea without using
the
Beeminder API. You could have a script [0] that fires once a week and
subtracts
3 from the total, which wouldn’t be too hard. The other downside is that
I
believe Danny and Bethany plan to obsolete permanently flat roads
eventually,
although your graph might be grandfathered-in. At the moment you should
be able
to make your road flat – I don’t know why you’re having problems.

The standard approach would be to make a “Set a Limit” goal that
increases by
three each week. Under this scheme you are trying to stay below a total
that
increases by three hours every week rather than trying to stay below
zero. It
would be mostly the same, but look slightly different. One actual
difference is that you get more leeway slowly rather than all at once.
(The
total hours of leeway would be the same.)

You need a custom goal to make roads zero-width, I think.

Best,
Alec

[0]: Or an IFTTT recipe. You could tell IFTTT to send an email to
Beeminder
once per week subtracting three from your total. As far as I can tell,
you need
a Gmail account to do this.

On Sun, Aug 18, 2013 at 05:02:41PM -0400, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having
trouble setting up the sort of goal I want. I know others are using
bedtime goals – I’ve read the recent thread on that topic – and I’m
hoping people will have suggestions for me? I want to leave a lot of
flexibility, at least at first, since this is going to be a real, real hard
one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m
starting with a gentle approach; for now I’m mostly just trying to cut down
on the nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer
that I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway
for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it
working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number
of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer
on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset
myself to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to
work. The main problem I’m hitting right up front is, I can’t find a way
to fix the goal line at a specific, flat value. I’m actually using a
“custom” type goal and even there I don’t see a way to do it. (I can make
it flat by dialing in a rate of change of 0, but it’s picking the value for
the centerline based on my initial data, of course, and I don’t want that.)
Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder?
How? (2) If not, is there a better way to model this that preserves most
of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

Groups “Akratics Anonymous” group.

To unsubscribe from this group and stop receiving emails from it, send

Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send

I too endorse Essy’s solution. Was it Joe Paravisini who first thought
of that? That’s who we seem to credit with the idea on
blog.beeminder.com/box
Maybe lots of people have thought of it independently. I thought it
was pretty ingenious when I first heard the idea.

I totally agree with all the replies to Matthias here, including
we’ll at worst grandfather people – but I bet we’ll find a way to
have the best of all worlds!).

General principles (at risk of being a broken record):

1. Mind a meaningful metric! (The QS First principle. Like have
Beeminder enforce something simple and inherently interesting like
average time you get to bed, or hours of sleep.)
2. The First Rule of Beeminder: Anything that makes it easier to stay
on track in the short term makes it harder down the Road.
blog.beeminder.com/catchup
3. If you end up having a beemergency every damn day (we’re akratics
after all) will that be reasonable/doable?

Matthias’s case:
The akrasia is compulsively staying up till 3am for no reason. But
that has to be turned into something graphable and it sounds like “be
in bed by 11pm or 11:30pm on average” is a reasonable proxy. If you
skate the edge then you’ll just have a consistent drop-dead bedtime
every night, adjustable by dialing the road. Go to bed early to build
up a safety buffer. I’m pretty sure that this is better than
artificially inserting effective resets on Sundays. Convincing?

On Mon, Aug 19, 2013 at 12:46 AM, Julian S julian86gtd@gmail.com wrote:

Hi Matthias,

Yes, I’ve implemented a similar goal to experiment with custom goals, so it
is possible (didn’t try zero road width though). However, it worked badly
and I would not advise using it. Why do you want to use such a system? There
may be alternative strategies to account for special behaviours or needs.

It seems clunky and less intuitive to me than using the system Essentiae
suggests (again similar to my own).

In spite of the e-mail reminders, there is less incentive to report with a
flat line rather than a moving limit, including pessimistic presumptive
reporting for set-a-limit goals. I don’t use PPR for my sleep goal though,
because the double-rate penalty seems a bit scary for me when I’m skating
near the edge (like today) and as I am pretty compulsive about keeping my
data current.

One of the great strengths of Beeminder is documenting a continuous habit,
so in my opinion, resetting every week doesn’t gel as well with the mindset
of establishing uniform routines over long periods of time. For sleep,
aiming for consistency and low variability is really important. It is also
easier to see interesting trends with the normal set-a-limit goals over
weeks, which are somewhat arbitrary divisions anyway. I should confess that
I do use some rules that Danny probably wouldn’t like, such as halving
values when I’m out on a Friday night, but they are fairly consistent and
planned.

More generally, when I first set up my sleep goal, I set an alarm to remind
me to turn off my computer (or at least social media/phone/distracting
websites) and try to go to bed. Remaining mindful of the habit becomes more
natural with time (I don’t need alarms anymore), but just remembering to
check the time is not always easy. I then added a physical calendar that
lives at my bed to ensure that I record the data, also without playing with
the computer or phone seconds before bed, as all that light makes it harder
to sleep.

Apologies for the rambling. I’m a little sleep deprived.

Cheers,

Julian

On Monday, August 19, 2013 10:16:09 AM UTC+10, Matthias Ferber wrote:

Hey Alec and Essentiae,

Thanks for your suggestions. Both of you suggested, basically, a limit
that increases by 3 weekly, and both of you pointed out exactly what’s wrong
with that approach: I won’t have the full leeway at the start of the week.
I would have no flexibility on the first night of the week, ever – if I
slip by even a minute, I derail, whereas by the end of the week I (might)
have lots of leeway. Not only is that arbitrary and sort of weird, but it’s
a near-guarantee that I’ll fail.

Still open to suggestions, and still pondering it myself. There’s got to
be a way to quantify this better.

Alec, to clarify: I should have said I was planning on resetting to 3
hours of buffer each week manually. I didn’t expect to automate that
(although your IFTTT idea is temptingly clever and I might use it if I ever
get this working). And I’m not having trouble getting the road flat, at
least not initially, or giving it a width of 0 – I’m using a custom goal.
What isn’t working is getting the road to stay at 0. Beeminder is setting
it flat at -3, matching my first data point (which was supposed to represent
my buffer for the week).

I’m trying an experiment where I leave today’s first data point at 0, and
wait till tomorrow to add the “reset” data point of -3 for this week. I’m
not sure if that will leave the line at 0 or not.

Any more ideas, anybody?

Thanks,
Matthias

On Aug 18, 2013, at 6:31 PM, Alec Brooks zab...@gmail.com wrote:

I don’t think there’s a way to implement your exact idea without using
the
Beeminder API. You could have a script [0] that fires once a week and
subtracts
3 from the total, which wouldn’t be too hard. The other downside is that
I
believe Danny and Bethany plan to obsolete permanently flat roads
eventually,
although your graph might be grandfathered-in. At the moment you should
be able
to make your road flat – I don’t know why you’re having problems.

The standard approach would be to make a “Set a Limit” goal that
increases by
three each week. Under this scheme you are trying to stay below a total
that
increases by three hours every week rather than trying to stay below
zero. It
would be mostly the same, but look slightly different. One actual
difference is that you get more leeway slowly rather than all at once.
(The
total hours of leeway would be the same.)

You need a custom goal to make roads zero-width, I think.

Best,
Alec

[0]: Or an IFTTT recipe. You could tell IFTTT to send an email to
Beeminder
once per week subtracting three from your total. As far as I can tell,
you need
a Gmail account to do this.

On Sun, Aug 18, 2013 at 05:02:41PM -0400, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having
trouble setting up the sort of goal I want. I know others are using bedtime
goals – I’ve read the recent thread on that topic – and I’m hoping people
will have suggestions for me? I want to leave a lot of flexibility, at
least at first, since this is going to be a real, real hard one for me to
stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m
starting with a gentle approach; for now I’m mostly just trying to cut down
on the nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer
that I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway
for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it
working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number
of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer
on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset
myself to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to
work. The main problem I’m hitting right up front is, I can’t find a way to
fix the goal line at a specific, flat value. I’m actually using a “custom”
type goal and even there I don’t see a way to do it. (I can make it flat by
dialing in a rate of change of 0, but it’s picking the value for the
centerline based on my initial data, of course, and I don’t want that.)
Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder?
How? (2) If not, is there a better way to model this that preserves most of
the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send

Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send

You received this message because you are subscribed to the Google Groups
“Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send an

http://dreev.es – search://“Daniel Reeves”
Goal tracking + Commitment contracts == http://beeminder.com

Convincing?

Er, no, not really. Not yet anyway. I haven’t had a lot of brainspace available to think about these responses yet and I think I need to review them more carefully, since there’s a clear consensus. I’m still pretty convinced that the “normal” buffer approaches aren’t going to work very well for me, at least at first, in this particular goal. But I’ll try to get clearer in my head as soon as I can, and maybe come back to this thread then. It would also probably help if I had a better understanding of what the tools are for controlling your safety margin – it’s probably some combination of retroratchet and maximum safe days, or something, but I don’t know exactly how either of those work yet.

I absolutely cannot have an emergency day every day, not with this goal. That way lies certain, continual failure.

In the meantime, can you guys at least clarify for me what’s wrong with a flat road? I just don’t see it. Why is it sensible to track a quantity you want to increase by 1 every day but not a quantity you don’t want to increase at all? Why is “hour at which I go to bed” a “meaningful” metric, but “number of hours I stay up past my bedtime” not meaningful? I’m missing something basic here, clearly. Can any of you elucidate?

For now, my goal does seem to be working the way I want it to. Whether it should be or not, and whether it will continue to after I derail (and I will), is TBD. But if there’s a better way to do it that Beeminder handles better and that still meets my needs, I’d be glad to be persuaded.

Gotta go. It’s 10 minutes to bedtime and I have some photos to edit.

Matthias

On Aug 20, 2013, at 2:38 AM, Daniel Reeves dreeves@beeminder.com wrote:

I too endorse Essy’s solution. Was it Joe Paravisini who first thought
of that? That’s who we seem to credit with the idea on
blog.beeminder.com/box
Maybe lots of people have thought of it independently. I thought it
was pretty ingenious when I first heard the idea.

I totally agree with all the replies to Matthias here, including
we’ll at worst grandfather people – but I bet we’ll find a way to
have the best of all worlds!).

General principles (at risk of being a broken record):

1. Mind a meaningful metric! (The QS First principle. Like have
Beeminder enforce something simple and inherently interesting like
average time you get to bed, or hours of sleep.)
2. The First Rule of Beeminder: Anything that makes it easier to stay
on track in the short term makes it harder down the Road.
blog.beeminder.com/catchup
3. If you end up having a beemergency every damn day (we’re akratics
after all) will that be reasonable/doable?

Matthias’s case:
The akrasia is compulsively staying up till 3am for no reason. But
that has to be turned into something graphable and it sounds like “be
in bed by 11pm or 11:30pm on average” is a reasonable proxy. If you
skate the edge then you’ll just have a consistent drop-dead bedtime
every night, adjustable by dialing the road. Go to bed early to build
up a safety buffer. I’m pretty sure that this is better than
artificially inserting effective resets on Sundays. Convincing?

On Mon, Aug 19, 2013 at 12:46 AM, Julian S julian86gtd@gmail.com wrote:

Hi Matthias,

Yes, I’ve implemented a similar goal to experiment with custom goals, so it
is possible (didn’t try zero road width though). However, it worked badly
and I would not advise using it. Why do you want to use such a system? There
may be alternative strategies to account for special behaviours or needs.

It seems clunky and less intuitive to me than using the system Essentiae
suggests (again similar to my own).

In spite of the e-mail reminders, there is less incentive to report with a
flat line rather than a moving limit, including pessimistic presumptive
reporting for set-a-limit goals. I don’t use PPR for my sleep goal though,
because the double-rate penalty seems a bit scary for me when I’m skating
near the edge (like today) and as I am pretty compulsive about keeping my
data current.

One of the great strengths of Beeminder is documenting a continuous habit,
so in my opinion, resetting every week doesn’t gel as well with the mindset
of establishing uniform routines over long periods of time. For sleep,
aiming for consistency and low variability is really important. It is also
easier to see interesting trends with the normal set-a-limit goals over
weeks, which are somewhat arbitrary divisions anyway. I should confess that
I do use some rules that Danny probably wouldn’t like, such as halving
values when I’m out on a Friday night, but they are fairly consistent and
planned.

More generally, when I first set up my sleep goal, I set an alarm to remind
me to turn off my computer (or at least social media/phone/distracting
websites) and try to go to bed. Remaining mindful of the habit becomes more
natural with time (I don’t need alarms anymore), but just remembering to
check the time is not always easy. I then added a physical calendar that
lives at my bed to ensure that I record the data, also without playing with
the computer or phone seconds before bed, as all that light makes it harder
to sleep.

Apologies for the rambling. I’m a little sleep deprived.

Cheers,

Julian

On Monday, August 19, 2013 10:16:09 AM UTC+10, Matthias Ferber wrote:

Hey Alec and Essentiae,

Thanks for your suggestions. Both of you suggested, basically, a limit
that increases by 3 weekly, and both of you pointed out exactly what’s wrong
with that approach: I won’t have the full leeway at the start of the week.
I would have no flexibility on the first night of the week, ever – if I
slip by even a minute, I derail, whereas by the end of the week I (might)
have lots of leeway. Not only is that arbitrary and sort of weird, but it’s
a near-guarantee that I’ll fail.

Still open to suggestions, and still pondering it myself. There’s got to
be a way to quantify this better.

Alec, to clarify: I should have said I was planning on resetting to 3
hours of buffer each week manually. I didn’t expect to automate that
(although your IFTTT idea is temptingly clever and I might use it if I ever
get this working). And I’m not having trouble getting the road flat, at
least not initially, or giving it a width of 0 – I’m using a custom goal.
What isn’t working is getting the road to stay at 0. Beeminder is setting
it flat at -3, matching my first data point (which was supposed to represent
my buffer for the week).

I’m trying an experiment where I leave today’s first data point at 0, and
wait till tomorrow to add the “reset” data point of -3 for this week. I’m
not sure if that will leave the line at 0 or not.

Any more ideas, anybody?

Thanks,
Matthias

On Aug 18, 2013, at 6:31 PM, Alec Brooks zab...@gmail.com wrote:

I don’t think there’s a way to implement your exact idea without using
the
Beeminder API. You could have a script [0] that fires once a week and
subtracts
3 from the total, which wouldn’t be too hard. The other downside is that
I
believe Danny and Bethany plan to obsolete permanently flat roads
eventually,
although your graph might be grandfathered-in. At the moment you should
be able
to make your road flat – I don’t know why you’re having problems.

The standard approach would be to make a “Set a Limit” goal that
increases by
three each week. Under this scheme you are trying to stay below a total
that
increases by three hours every week rather than trying to stay below
zero. It
would be mostly the same, but look slightly different. One actual
difference is that you get more leeway slowly rather than all at once.
(The
total hours of leeway would be the same.)

You need a custom goal to make roads zero-width, I think.

Best,
Alec

[0]: Or an IFTTT recipe. You could tell IFTTT to send an email to
Beeminder
once per week subtracting three from your total. As far as I can tell,
you need
a Gmail account to do this.

On Sun, Aug 18, 2013 at 05:02:41PM -0400, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having
trouble setting up the sort of goal I want. I know others are using bedtime
goals – I’ve read the recent thread on that topic – and I’m hoping people
will have suggestions for me? I want to leave a lot of flexibility, at
least at first, since this is going to be a real, real hard one for me to
stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m
starting with a gentle approach; for now I’m mostly just trying to cut down
on the nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer
that I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway
for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it
working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number
of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer
on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset
myself to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to
work. The main problem I’m hitting right up front is, I can’t find a way to
fix the goal line at a specific, flat value. I’m actually using a “custom”
type goal and even there I don’t see a way to do it. (I can make it flat by
dialing in a rate of change of 0, but it’s picking the value for the
centerline based on my initial data, of course, and I don’t want that.)
Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder?
How? (2) If not, is there a better way to model this that preserves most of
the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send

Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send

You received this message because you are subscribed to the Google Groups
“Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send an

http://dreev.es – search://“Daniel Reeves”
Goal tracking + Commitment contracts == http://beeminder.com

A flat road requires more maintenance for no clear advantage. For the
proposed sleep system, one has to make the decision to restart the habit
each week, rather than just establishing a habit of going to sleep and
reporting one value per day. Hours past bedtime buffer and actual bedtime
are identical, but reporting a time rather than making a calculation also
has near zero margin for error.

Measures to help ensure reporting are critical. Another system to tweak if
you are worried about constant derailing might be to set a custom road
width with a similarly conservative increasing rate, but with pessimistic
presumptive reporting turned on, and then resolve to stay off the road
entirely. I believe many have problems with that, but I personally find
that even the additional yellow guidelines are useful. The (+) values for
each lane on the yellow brick road and visual representation are also more
useful to me than the number of safe days. I almost never retroratchet as I
try to have meaningful rates for goals with a minimum of thought and
intervention.

If you find the ritual of taking these small additional steps with a flat
road personally useful, that’s good, but I suspect that it would lead to
failure for most people.

Cheers,

Julian

On Wednesday, August 21, 2013 12:50:19 PM UTC+10, Matthias Ferber wrote:

Convincing?

Er, no, not really. Not yet anyway. I haven’t had a lot of brainspace
available to think about these responses yet and I think I need to review
them more carefully, since there’s a clear consensus. I’m still pretty
convinced that the “normal” buffer approaches aren’t going to work very
well for me, at least at first, in this particular goal. But I’ll try to
get clearer in my head as soon as I can, and maybe come back to this thread
then. It would also probably help if I had a better understanding of what
the tools are for controlling your safety margin – it’s probably some
combination of retroratchet and maximum safe days, or something, but I
don’t know exactly how either of those work yet.

I absolutely cannot have an emergency day every day, not with this goal.
That way lies certain, continual failure.

In the meantime, can you guys at least clarify for me what’s wrong with a
flat road? I just don’t see it. Why is it sensible to track a quantity
you want to increase by 1 every day but not a quantity you don’t want to
increase at all? Why is “hour at which I go to bed” a “meaningful” metric,
but “number of hours I stay up past my bedtime” not meaningful? I’m
missing something basic here, clearly. Can any of you elucidate?

For now, my goal does seem to be working the way I want it to. Whether it
should be or not, and whether it will continue to after I derail (and I
will), is TBD. But if there’s a better way to do it that Beeminder handles
better and that still meets my needs, I’d be glad to be persuaded.

Gotta go. It’s 10 minutes to bedtime and I have some photos to edit.

Matthias

On Aug 20, 2013, at 2:38 AM, Daniel Reeves <dre...@beeminder.com<javascript:>>
wrote:

I too endorse Essy’s solution. Was it Joe Paravisini who first thought
of that? That’s who we seem to credit with the idea on
blog.beeminder.com/box
Maybe lots of people have thought of it independently. I thought it
was pretty ingenious when I first heard the idea.

I totally agree with all the replies to Matthias here, including
we’ll at worst grandfather people – but I bet we’ll find a way to
have the best of all worlds!).

General principles (at risk of being a broken record):

1. Mind a meaningful metric! (The QS First principle. Like have
Beeminder enforce something simple and inherently interesting like
average time you get to bed, or hours of sleep.)
2. The First Rule of Beeminder: Anything that makes it easier to stay
on track in the short term makes it harder down the Road.
blog.beeminder.com/catchup
3. If you end up having a beemergency every damn day (we’re akratics
after all) will that be reasonable/doable?

Matthias’s case:
The akrasia is compulsively staying up till 3am for no reason. But
that has to be turned into something graphable and it sounds like “be
in bed by 11pm or 11:30pm on average” is a reasonable proxy. If you
skate the edge then you’ll just have a consistent drop-dead bedtime
every night, adjustable by dialing the road. Go to bed early to build
up a safety buffer. I’m pretty sure that this is better than
artificially inserting effective resets on Sundays. Convincing?

On Mon, Aug 19, 2013 at 12:46 AM, Julian S <julia...@gmail.com<javascript:>>
wrote:

Hi Matthias,

Yes, I’ve implemented a similar goal to experiment with custom goals,
so it

is possible (didn’t try zero road width though). However, it worked

and I would not advise using it. Why do you want to use such a system?
There

may be alternative strategies to account for special behaviours or
needs.

It seems clunky and less intuitive to me than using the system
Essentiae

suggests (again similar to my own).

In spite of the e-mail reminders, there is less incentive to report
with a

flat line rather than a moving limit, including pessimistic presumptive
reporting for set-a-limit goals. I don’t use PPR for my sleep goal
though,

because the double-rate penalty seems a bit scary for me when I’m
skating

near the edge (like today) and as I am pretty compulsive about keeping
my

data current.

One of the great strengths of Beeminder is documenting a continuous
habit,

so in my opinion, resetting every week doesn’t gel as well with the
mindset

of establishing uniform routines over long periods of time. For sleep,
aiming for consistency and low variability is really important. It is
also

easier to see interesting trends with the normal set-a-limit goals over
weeks, which are somewhat arbitrary divisions anyway. I should confess
that

I do use some rules that Danny probably wouldn’t like, such as halving
values when I’m out on a Friday night, but they are fairly consistent
and

planned.

More generally, when I first set up my sleep goal, I set an alarm to
remind

me to turn off my computer (or at least social media/phone/distracting
websites) and try to go to bed. Remaining mindful of the habit becomes
more

natural with time (I don’t need alarms anymore), but just remembering
to

check the time is not always easy. I then added a physical calendar
that

lives at my bed to ensure that I record the data, also without playing
with

the computer or phone seconds before bed, as all that light makes it
harder

to sleep.

Apologies for the rambling. I’m a little sleep deprived.

Cheers,

Julian

On Monday, August 19, 2013 10:16:09 AM UTC+10, Matthias Ferber wrote:

Hey Alec and Essentiae,

Thanks for your suggestions. Both of you suggested, basically, a
limit

that increases by 3 weekly, and both of you pointed out exactly what’s
wrong

with that approach: I won’t have the full leeway at the start of the
week.

I would have no flexibility on the first night of the week, ever – if
I

slip by even a minute, I derail, whereas by the end of the week I
(might)

have lots of leeway. Not only is that arbitrary and sort of weird,
but it’s

a near-guarantee that I’ll fail.

Still open to suggestions, and still pondering it myself. There’s got
to

be a way to quantify this better.

Alec, to clarify: I should have said I was planning on resetting to 3
hours of buffer each week manually. I didn’t expect to automate that
(although your IFTTT idea is temptingly clever and I might use it if I
ever

get this working). And I’m not having trouble getting the road flat,
at

least not initially, or giving it a width of 0 – I’m using a custom
goal.

What isn’t working is getting the road to stay at 0. Beeminder is
setting

it flat at -3, matching my first data point (which was supposed to
represent

my buffer for the week).

I’m trying an experiment where I leave today’s first data point at 0,
and

wait till tomorrow to add the “reset” data point of -3 for this week.
I’m

not sure if that will leave the line at 0 or not.

Any more ideas, anybody?

Thanks,
Matthias

On Aug 18, 2013, at 6:31 PM, Alec Brooks zab...@gmail.com wrote:

I don’t think there’s a way to implement your exact idea without
using

the
Beeminder API. You could have a script [0] that fires once a week and
subtracts
3 from the total, which wouldn’t be too hard. The other downside is
that

I
believe Danny and Bethany plan to obsolete permanently flat roads
eventually,
although your graph might be grandfathered-in. At the moment you
should

be able
to make your road flat – I don’t know why you’re having problems.

The standard approach would be to make a “Set a Limit” goal that
increases by
three each week. Under this scheme you are trying to stay below a
total

that
increases by three hours every week rather than trying to stay below
zero. It
would be mostly the same, but look slightly different. One actual
difference is that you get more leeway slowly rather than all at
once.

(The
total hours of leeway would be the same.)

You need a custom goal to make roads zero-width, I think.

Best,
Alec

[0]: Or an IFTTT recipe. You could tell IFTTT to send an email to
Beeminder
once per week subtracting three from your total. As far as I can
tell,

you need
a Gmail account to do this.

On Sun, Aug 18, 2013 at 05:02:41PM -0400, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m
having

trouble setting up the sort of goal I want. I know others are using
bedtime

goals – I’ve read the recent thread on that topic – and I’m hoping
people

will have suggestions for me? I want to leave a lot of flexibility,
at

least at first, since this is going to be a real, real hard one for
me to

stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m
starting with a gentle approach; for now I’m mostly just trying to
cut down

on the nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer
that I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn
leeway

for nights later in the week).

• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it
working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed
(number

of hours past 11:00).

• The YBR is effectively zero-width: I don’t want any additional
buffer

on the “good side”.

• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset
myself to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it
to

work. The main problem I’m hitting right up front is, I can’t find
a way to

fix the goal line at a specific, flat value. I’m actually using a
“custom”

type goal and even there I don’t see a way to do it. (I can make it
flat by

dialing in a rate of change of 0, but it’s picking the value for the
centerline based on my initial data, of course, and I don’t want
that.)

Beeminder also seems to really prefer values that increase or
decrease.

My question to you all is: (1) Can this be implemented in
Beeminder?

How? (2) If not, is there a better way to model this that preserves
most of

the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it,
send

Groups “Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it,
send

Groups

“Akratics Anonymous” group.
To unsubscribe from this group and stop receiving emails from it, send
an

http://dreev.es – search://“Daniel Reeves”
Goal tracking + Commitment contracts == http://beeminder.com

Have been thinking going to sleep early and this is what I am planning to
do.

Set a do more goal. Create a points system.
1 point for going to bed by 11pm
2 points for … by 10 pm
0 points for … by 12 midnight
-1 points for … by 1 am
-2 points for … beyond 1 am

Set a weekly target of 5 points / week, so if you are good and sleep by
11pm 5 days a week, you are ok.
To build a buffer you would have to sleep by 10 pm on some days. Or you
could reduce the weekly target to 3 or 4 so that sleeping by 11 pm 5 days a
week builds a buffer automatically.

On Monday, 19 August 2013 02:32:41 UTC+5:30, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having
trouble setting up the sort of goal I want. I know others are using
bedtime goals – I’ve read the recent thread on that topic – and I’m
hoping people will have suggestions for me? I want to leave a lot of
flexibility, at least at first, since this is going to be a real, real hard
one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m starting
with a gentle approach; for now I’m mostly just trying to cut down on the
nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer that I
can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway for
nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number of
hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer on
the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset myself
to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to
work. The main problem I’m hitting right up front is, I can’t find a way
to fix the goal line at a specific, flat value. I’m actually using a
"custom" type goal and even there I don’t see a way to do it. (I can make
it flat by dialing in a rate of change of 0, but it’s picking the value for
the centerline based on my initial data, of course, and I don’t want that.)
Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder?
How? (2) If not, is there a better way to model this that preserves most
of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

This is a nice idea, let us know how it works out! One possible downside is
the ability to be really inconsistent, which isn’t great for a sleep
schedule, but if you find that happening you could probably reduce the
number of (positive?) points on the scale. But even then, getting more
sleep some of the time could be a valuable incremental improvement.

On Wednesday, November 20, 2013 4:45:31 AM UTC-5, Aditya Bhattacharyya
wrote:

Have been thinking going to sleep early and this is what I am planning to
do.

Set a do more goal. Create a points system.
1 point for going to bed by 11pm
2 points for … by 10 pm
0 points for … by 12 midnight
-1 points for … by 1 am
-2 points for … beyond 1 am

Set a weekly target of 5 points / week, so if you are good and sleep by
11pm 5 days a week, you are ok.
To build a buffer you would have to sleep by 10 pm on some days. Or you
could reduce the weekly target to 3 or 4 so that sleeping by 11 pm 5 days a
week builds a buffer automatically.

On Monday, 19 August 2013 02:32:41 UTC+5:30, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having
trouble setting up the sort of goal I want. I know others are using
bedtime goals – I’ve read the recent thread on that topic – and I’m
hoping people will have suggestions for me? I want to leave a lot of
flexibility, at least at first, since this is going to be a real, real hard
one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m starting
with a gentle approach; for now I’m mostly just trying to cut down on the
nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer that
I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway
for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number
of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer
on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset myself
to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to
work. The main problem I’m hitting right up front is, I can’t find a way
to fix the goal line at a specific, flat value. I’m actually using a
"custom" type goal and even there I don’t see a way to do it. (I can make
it flat by dialing in a rate of change of 0, but it’s picking the value for
the centerline based on my initial data, of course, and I don’t want that.)
Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder?
How? (2) If not, is there a better way to model this that preserves most
of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias

Thanks Presley.
Just a week into it. Mixed results.
Ate up most of my 7 day starting buffer - found it very difficult to sleep
by 11.
Once I did start though, it was easier to continue.
Also one day a party happened, so slept at 2am, but the offshoot was that I
was so tired that I slept at 10pm the next day, so while I lost 2 points I
gained them back the next day. So suspect that - like you said - one can be
really inconsistent with ones sleep habits and still get away with it.
Maybe one can tweak the points to be stricter on weekdays and lax on
weekends…
Anyways will tweak as we go along and then post again.

On Wednesday, 20 November 2013 20:59:17 UTC+5:30, Presley Pizzo wrote:

This is a nice idea, let us know how it works out! One possible downside
is the ability to be really inconsistent, which isn’t great for a sleep
schedule, but if you find that happening you could probably reduce the
number of (positive?) points on the scale. But even then, getting more
sleep some of the time could be a valuable incremental improvement.

On Wednesday, November 20, 2013 4:45:31 AM UTC-5, Aditya Bhattacharyya
wrote:

Have been thinking going to sleep early and this is what I am planning to
do.

Set a do more goal. Create a points system.
1 point for going to bed by 11pm
2 points for … by 10 pm
0 points for … by 12 midnight
-1 points for … by 1 am
-2 points for … beyond 1 am

Set a weekly target of 5 points / week, so if you are good and sleep by
11pm 5 days a week, you are ok.
To build a buffer you would have to sleep by 10 pm on some days. Or you
could reduce the weekly target to 3 or 4 so that sleeping by 11 pm 5 days a
week builds a buffer automatically.

On Monday, 19 August 2013 02:32:41 UTC+5:30, Matthias Ferber wrote:

Hey akratics nerds,

I’m starting to experiment with beeminding my bedtime, and I’m having
trouble setting up the sort of goal I want. I know others are using
bedtime goals – I’ve read the recent thread on that topic – and I’m
hoping people will have suggestions for me? I want to leave a lot of
flexibility, at least at first, since this is going to be a real, real hard
one for me to stick to.

Here’s the ideal behavior I’d like to have – as you’ll see I’m starting
with a gentle approach; for now I’m mostly just trying to cut down on the
nights I compulsively stay up till 3 a.m. for no reason.

• Aim: to be in bed by 11 every night.
• Every Sunday, I start fresh with exactly 3 hours of “free” buffer that
I can “spend” throughout the week.
• When I go to bed earlier than 11, my buffer increases (I earn leeway
for nights later in the week).
• If I use up my buffer, I derail.

The problem is in the implementation. Here’s how I imagined it working:

• My goal line is flat, at 0. [Maybe not possible? See below.]
• Each day I add a data point for how late I was getting to bed (number
of hours past 11:00).
• The YBR is effectively zero-width: I don’t want any additional buffer
on the “good side”.
• If I go above the zero line, I derail.
• Every Sunday I add a dummy entry to reset myself to -3.

[Alternatively, the YBR could have a fixed width of 3 and I reset myself
to 0 every week; not sure that makes a difference.]

I think this is sort of a “set a limit” goal, but I’m not getting it to
work. The main problem I’m hitting right up front is, I can’t find a way
to fix the goal line at a specific, flat value. I’m actually using a
"custom" type goal and even there I don’t see a way to do it. (I can make
it flat by dialing in a rate of change of 0, but it’s picking the value for
the centerline based on my initial data, of course, and I don’t want that.)
Beeminder also seems to really prefer values that increase or decrease.

My question to you all is: (1) Can this be implemented in Beeminder?
How? (2) If not, is there a better way to model this that preserves most
of the behavior I want?

Thanks for reading, everybody, this is a lot of detail here.

Matthias