2013-01-09 20:07:09 +00:00
|
|
|
#include <string.h>
|
|
|
|
#include "dive.h"
|
|
|
|
#include "device.h"
|
|
|
|
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
/*
|
|
|
|
* Good fake dive profiles are hard.
|
|
|
|
*
|
|
|
|
* "depthtime" is the integral of the dive depth over
|
|
|
|
* time ("area" of the dive profile). We want that
|
|
|
|
* area to match the average depth (avg_d*max_t).
|
|
|
|
*
|
|
|
|
* To do that, we generate a 6-point profile:
|
|
|
|
*
|
|
|
|
* (0, 0)
|
|
|
|
* (t1, max_d)
|
2014-01-08 13:46:27 +00:00
|
|
|
* (t2, max_d)
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
* (t3, d)
|
2014-01-08 13:46:27 +00:00
|
|
|
* (t4, d)
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
* (max_t, 0)
|
|
|
|
*
|
|
|
|
* with the same ascent/descent rates between the
|
|
|
|
* different depths.
|
|
|
|
*
|
|
|
|
* NOTE: avg_d, max_d and max_t are given constants.
|
|
|
|
* The rest we can/should play around with to get a
|
|
|
|
* good-looking profile.
|
|
|
|
*
|
|
|
|
* That six-point profile gives a total area of:
|
|
|
|
*
|
|
|
|
* (max_d*max_t) - (max_d*t1) - (max_d-d)*(t4-t3)
|
|
|
|
*
|
|
|
|
* And the "same ascent/descent rates" requirement
|
|
|
|
* gives us (time per depth must be same):
|
|
|
|
*
|
|
|
|
* t1 / max_d = (t3-t2) / (max_d-d)
|
|
|
|
* t1 / max_d = (max_t-t4) / d
|
|
|
|
*
|
|
|
|
* We also obviously require:
|
|
|
|
*
|
|
|
|
* 0 <= t1 <= t2 <= t3 <= t4 <= max_t
|
|
|
|
*
|
|
|
|
* Let us call 'd_frac = d / max_d', and we get:
|
|
|
|
*
|
|
|
|
* Total area must match average depth-time:
|
|
|
|
*
|
|
|
|
* (max_d*max_t) - (max_d*t1) - (max_d-d)*(t4-t3) = avg_d*max_t
|
|
|
|
* max_d*(max_t-t1-(1-d_frac)*(t4-t3)) = avg_d*max_t
|
|
|
|
* max_t-t1-(1-d_frac)*(t4-t3) = avg_d*max_t/max_d
|
|
|
|
* t1+(1-d_frac)*(t4-t3) = max_t*(1-avg_d/max_d)
|
|
|
|
*
|
|
|
|
* and descent slope must match ascent slopes:
|
|
|
|
*
|
|
|
|
* t1 / max_d = (t3-t2) / (max_d*(1-d_frac))
|
|
|
|
* t1 = (t3-t2)/(1-d_frac)
|
|
|
|
*
|
|
|
|
* and
|
|
|
|
*
|
|
|
|
* t1 / max_d = (max_t-t4) / (max_d*d_frac)
|
|
|
|
* t1 = (max_t-t4)/d_frac
|
|
|
|
*
|
|
|
|
* In general, we have more free variables than we have constraints,
|
|
|
|
* but we can aim for certain basics, like a good ascent slope.
|
|
|
|
*/
|
|
|
|
static int fill_samples(struct sample *s, int max_d, int avg_d, int max_t, double slope, double d_frac)
|
|
|
|
{
|
2014-02-28 04:09:57 +00:00
|
|
|
double t_frac = max_t * (1 - avg_d / (double)max_d);
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
int t1 = max_d / slope;
|
2014-02-28 04:09:57 +00:00
|
|
|
int t4 = max_t - t1 * d_frac;
|
|
|
|
int t3 = t4 - (t_frac - t1) / (1 - d_frac);
|
|
|
|
int t2 = t3 - t1 * (1 - d_frac);
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
if (t1 < 0 || t1 > t2 || t2 > t3 || t3 > t4 || t4 > max_t)
|
|
|
|
return 0;
|
|
|
|
|
2014-02-28 04:09:57 +00:00
|
|
|
s[1].time.seconds = t1;
|
|
|
|
s[1].depth.mm = max_d;
|
|
|
|
s[2].time.seconds = t2;
|
|
|
|
s[2].depth.mm = max_d;
|
|
|
|
s[3].time.seconds = t3;
|
|
|
|
s[3].depth.mm = max_d * d_frac;
|
|
|
|
s[4].time.seconds = t4;
|
|
|
|
s[4].depth.mm = max_d * d_frac;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-01-08 13:46:27 +00:00
|
|
|
/* we have no average depth; instead of making up a random average depth
|
2015-11-15 18:15:40 +00:00
|
|
|
* we should assume either a PADI rectangular profile (for short and/or
|
2014-01-08 13:46:27 +00:00
|
|
|
* shallow dives) or more reasonably a six point profile with a 3 minute
|
|
|
|
* safety stop at 5m */
|
|
|
|
static void fill_samples_no_avg(struct sample *s, int max_d, int max_t, double slope)
|
|
|
|
{
|
|
|
|
// shallow or short dives are just trapecoids based on the given slope
|
|
|
|
if (max_d < 10000 || max_t < 600) {
|
2014-02-28 04:09:57 +00:00
|
|
|
s[1].time.seconds = max_d / slope;
|
|
|
|
s[1].depth.mm = max_d;
|
|
|
|
s[2].time.seconds = max_t - max_d / slope;
|
|
|
|
s[2].depth.mm = max_d;
|
2014-01-08 13:46:27 +00:00
|
|
|
} else {
|
|
|
|
s[1].time.seconds = max_d / slope;
|
|
|
|
s[1].depth.mm = max_d;
|
|
|
|
s[2].time.seconds = max_t - max_d / slope - 180;
|
|
|
|
s[2].depth.mm = max_d;
|
|
|
|
s[3].time.seconds = max_t - 5000 / slope - 180;
|
|
|
|
s[3].depth.mm = 5000;
|
|
|
|
s[4].time.seconds = max_t - 5000 / slope;
|
|
|
|
s[4].depth.mm = 5000;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-20 17:36:14 +00:00
|
|
|
struct divecomputer *fake_dc(struct divecomputer *dc, bool alloc)
|
2013-06-10 16:35:27 +00:00
|
|
|
{
|
2016-02-20 17:36:14 +00:00
|
|
|
static struct sample fake_samples[6];
|
2013-06-10 16:35:27 +00:00
|
|
|
static struct divecomputer fakedc;
|
2016-02-20 17:36:14 +00:00
|
|
|
struct sample *fake = fake_samples;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
|
|
|
|
fakedc = (*dc);
|
2016-02-20 17:36:14 +00:00
|
|
|
if (alloc)
|
|
|
|
fake = malloc(sizeof(fake_samples));
|
|
|
|
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
fakedc.sample = fake;
|
|
|
|
fakedc.samples = 6;
|
|
|
|
|
|
|
|
/* The dive has no samples, so create a few fake ones */
|
|
|
|
int max_t = dc->duration.seconds;
|
|
|
|
int max_d = dc->maxdepth.mm;
|
|
|
|
int avg_d = dc->meandepth.mm;
|
|
|
|
|
2016-02-20 17:36:14 +00:00
|
|
|
memset(fake, 0, sizeof(fake_samples));
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
fake[5].time.seconds = max_t;
|
|
|
|
if (!max_t || !max_d)
|
|
|
|
return &fakedc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We want to fake the profile so that the average
|
2015-11-15 18:15:40 +00:00
|
|
|
* depth ends up correct. However, in the absence of
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
* a reasonable average, let's just make something
|
|
|
|
* up. Note that 'avg_d == max_d' is _not_ a reasonable
|
|
|
|
* average.
|
2014-01-08 13:46:27 +00:00
|
|
|
* We explicitly treat avg_d == 0 differently */
|
|
|
|
if (avg_d == 0) {
|
|
|
|
/* we try for a sane slope, but bow to the insanity of
|
|
|
|
* the user supplied data */
|
|
|
|
fill_samples_no_avg(fake, max_d, max_t, MAX(2.0 * max_d / max_t, 5000.0 / 60));
|
2014-01-16 04:50:56 +00:00
|
|
|
if (fake[3].time.seconds == 0) { // just a 4 point profile
|
2014-01-08 13:46:27 +00:00
|
|
|
fakedc.samples = 4;
|
|
|
|
fake[3].time.seconds = max_t;
|
|
|
|
}
|
|
|
|
return &fakedc;
|
|
|
|
}
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
if (avg_d < max_d / 10 || avg_d >= max_d) {
|
2014-02-28 04:09:57 +00:00
|
|
|
avg_d = (max_d + 10000) / 3;
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
if (avg_d > max_d)
|
|
|
|
avg_d = max_d * 2 / 3;
|
2013-06-10 16:35:27 +00:00
|
|
|
}
|
Make fake profile average depth come out right
This isn't perfect as it doesn't really cover all cases. If we need to
generate a profile for some fairly insane cases, the stupid thing just
gives up rather than try to search for a solution that satisfies the
constraints.
For example, if you have a maxdepth=10m and an average depth of 9.9m, it
will try two different (roughly sane) dive profiles, fail to get anything
that matches that kind of dive and that average depth, and then just say
"screw it, I'll match an insane profile instead" and basically generate a
rectangular dive.
It does seem to handle the few cases I tried.
Somebody should double-check my math, and I think we might want to make
the "default profiles" a bit saner. Right now the preferred default
profile simply says "ascent/descent rate of 5m/min, with two levels at
max_depth and 1/3rd maxdepth".
That profile might not work for the simple reason that maybe we did a
quick dive to 40m, but then came up and spent a lot of time in shallower
waters, so our average depth was just 10m or so. Obviously we can *not*
make a dive that has the two depths 40m and 13m come out to an average of
10m deep.
So it has a fallback for things like that, where we try to generate a
profile with a faster ascent/descent rate, and a shallower second depth.
And then there's the fallback with an insane 10m/s ascent/descent rate and
a second depth that is basically at the surface, and if we can't generate
a dive profile with those parameters, either my math is wrong, or somebody
was playing with rockets under-water. So we just give up.
There's a few other heuristics too (if there is no average depth, we
create a random one just to make the profile look reasonable).
I *think* this is all perfectly fine, but I do want others to take a look.
It might be doing something stupid.
[Dirk Hohndel: after the discussion I took the patch and reworded parts of
the commit message]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-10-15 18:36:21 +00:00
|
|
|
if (!avg_d)
|
|
|
|
avg_d = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ok, first we try a basic profile with a specific ascent
|
|
|
|
* rate (5 meters per minute) and d_frac (1/3).
|
|
|
|
*/
|
|
|
|
if (fill_samples(fake, max_d, avg_d, max_t, 5000.0 / 60, 0.33))
|
|
|
|
return &fakedc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ok, assume that didn't work because we cannot make the
|
|
|
|
* average come out right because it was a quick deep dive
|
|
|
|
* followed by a much shallower region
|
|
|
|
*/
|
|
|
|
if (fill_samples(fake, max_d, avg_d, max_t, 10000.0 / 60, 0.10))
|
|
|
|
return &fakedc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Uhhuh. That didn't work. We'd need to find a good combination that
|
|
|
|
* satisfies our constraints. Currently, we don't, we just give insane
|
|
|
|
* slopes.
|
|
|
|
*/
|
|
|
|
if (fill_samples(fake, max_d, avg_d, max_t, 10000.0, 0.01))
|
|
|
|
return &fakedc;
|
|
|
|
|
|
|
|
/* Even that didn't work? Give up, there's something wrong */
|
2013-06-10 16:35:27 +00:00
|
|
|
return &fakedc;
|
|
|
|
}
|
2016-06-21 04:07:36 +00:00
|
|
|
|
|
|
|
static void match_id(void *_dc, const char *model, uint32_t deviceid,
|
|
|
|
const char *nickname, const char *serial, const char *firmware)
|
|
|
|
{
|
2016-08-16 18:31:31 +00:00
|
|
|
// here nickname is unused
|
|
|
|
(void)nickname;
|
|
|
|
|
2016-06-21 04:07:36 +00:00
|
|
|
struct divecomputer *dc = _dc;
|
|
|
|
|
|
|
|
if (dc->deviceid != deviceid)
|
|
|
|
return;
|
2016-09-20 16:10:02 +00:00
|
|
|
if (!model || !dc->model || strcmp(dc->model, model))
|
2016-06-21 04:07:36 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (serial && !dc->serial)
|
|
|
|
dc->serial = strdup(serial);
|
|
|
|
if (firmware && !dc->fw_version)
|
|
|
|
dc->fw_version = strdup(firmware);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When setting the device ID, we also fill in the
|
|
|
|
* serial number and firmware version data
|
|
|
|
*/
|
|
|
|
void set_dc_deviceid(struct divecomputer *dc, unsigned int deviceid)
|
|
|
|
{
|
|
|
|
if (deviceid) {
|
|
|
|
dc->deviceid = deviceid;
|
|
|
|
call_for_each_dc(dc, match_id, false);
|
|
|
|
}
|
|
|
|
}
|