Vlad, > On 19. Apr 2023, at 11:38, Vlad A <[email protected]> wrote: > > That will simplify code by a lot. It should support mathematical operations > and comparison. If function return depth and you want to multiply it by > scalier to get depth you will end you with rather lengthy expression. > You can not just write depth_t D = getDepth() * myScaler and it gets worse > with cross unit operations. would be nice to just write > > depth_t deltaD = getAscentRate() * getInterval(); > currentDepth += deltaD; > > In this case, first function will return rate_t, second - duration_t, and > then rate_t should have multiplying operator which return depth_t if > multiplied by unit of time. I mean, sure, you can get around with C syntax > but it's kinda long, harder to read and notice how int's start crawling into > the code. > > int deltaD = getAscentRate().mms * getInterval().seconds; > currentDepth.mm += deltaD; > > Another aspect is unit conversion. For instance. depth, should have all > readers to read the number as mm, inch, feet, mashing-machine-size you name > it. Cause currently nothing stops you to feed wrong unit into wrong helper > function. Also you can just do > > pressure_t P = currentDepth.getPressure( dive ); > > This construction is fool proof. You cannot confuse units. And it's readable > in a glance. It's simple to do, but it will effectively nuke all .c files, > cause you'll loose ability to use those units from plain C. So I guess it's > not happening too soon.
exactly. In fact, I think that last bit is an underestimate. Apart from that, I think one should not be too dogmatic: If stuff becomes too long, it is ok to use just ints for example for local variables not to be come too verbose as long as you know what you are doing and use good variable names that make it clear what that variable represents. > > Even right now, with the small changes I've got so far it has HUGE domino > effect on a code base. I'll try to minimize the number of changes, but first > submit will be kinda big. > > As of your last question about ideas which lead to all this in a first place. > There's couple. Number one, and probably the biggest, is I would like to see > planner working on mobile. Which might lead to big rethinking of UI. Editing > profile the way we do right now in the planner will be a bit to much for a > small screen. Also, you don't have all the widgets you have on PC. Of course, many people before had the idea to port the planner to mobile. But you are correct what is the major stumbling block: Design a reasonable UI that works with touch and without a keyboard but with limited screen estate. I don't think the world needs another dive planner with a million of scroll wheels to enter numbers for depths and durations which then, after pressing a "calculate" button produces a dive plan. That already exists. The Subsurface planner (in the desktop version) is different and from my point of view its main strength is the interactiveness, everything you change is immediately reflected in the dive plan (including when you drag waypoints with the mouse on the profile). I strongly believe that for a mobile planner the first step has to be to come up with a reasonable plan for a UI and possibly a mock up of it first. Hooking stuff up to calculations is then trivial in comparison. > And some folks mention that they are afraid to use Subsurface planner cause > it looks too overwhelming. This is something I personally disagree, but hey, > there's that. If we can modify UI to make it a bit more approachable. I mean, > presets, hide some stuff under some "Show advanced settings" checkbox, e.t.c. I agree that for a novice user the UI of the planner is far too baroque and has far too many handles and parameters. I would claim that that is just the optical impression and that most of that settings have sane default values and it is save to simply ignore most of them but that could definitely be presented to the user in a better way. But I would say, that is in the UI of the planner. That is neither planner.c nor deco.c but the stuff that is already in (Qt style) C++ like diveplanner.cpp and its friends. > Anyway, all of that require planner to be more modular. And right now it's > more of a monolithic thing. One huge function pulling all strings. > Same goes about plannernotes.cpp, note generation is again > one-thing-that-does-it-all. The logic in that file is totally nuts. But again, it solves a difficult problem: Condense the information about the deco schedule in a way useful to the human user. Deciding for example at which point to show a gaschange is surprisingly difficult. A large part of the problem is that there are two complementary viewpoints of a plan: You can either thing of the waypoints (the struct divepoint dp) as representing instances of time where something happens (you are at a certain depth, you change what you breath in a certain way) or alternatively you can think of them representing the interval of time since the previous dp, for example "a five minute ascent from 40m to 21m". If you change gas at 21m to EAN50, you want to attach that to the instant of time when you change it but if you think of intervals, you want to attach it to the _following_ interval since that is what is breathed from now on. Plus there are more complications, like two consecutive ascents segments that just differ in the ascent velocity. Those you want to present to the user as a single ascent. And then, to complicate things even more, there is the representation as a runtime table and alternatively as "verbose text", which again is different since the latter is much more in the "ascent in 2 min to 21m and then (instant of time!) switch to EAN50". An alternative might be to create the notes while computing the plan and not after the fact trying to create it from the list of dp's but if done naively, that would even move more functionality into what happens in planner.c. > Some people asked me whether it's possible to add more explain-ability to the > diveplan. That include many things, but most of the time it will require > ability to do calculations while generating tables, while right now you only > can use what planner have prepared in advance. What I just said. What exactly do you intend "more explainability" to be? I guess, you don't mean the verbose plan mode. Best Robert _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
