text:
• 0 Vote(s) - 0 Average
• 1
• 2
• 3
• 4
• 5
 [Update] Comparision of 5 methods of interpolation to continuous tetration Gottfried Ultimate Fellow Posts: 853 Threads: 126 Joined: Aug 2007 10/16/2013, 12:54 PM (This post was last modified: 10/16/2013, 01:04 PM by Gottfried.) (10/15/2013, 07:14 PM)sheldonison Wrote: Gottfried, I think your solution is interesting. I see from your paper, that the solution you get is real valued. Presumably, there is some sort of Taylor series representation for your solution. I would be interested in seeing a Taylor series at sexp(0) where sexp(0)=1. The Kneser solution is defined by two basic things; which your solution would need to match to converge. 1) it is real valued (it sounds like your function is also real valued). 2) the sexp limiting behavior in the complex plane, as imag(z) increases, is the same as the Schroeder function solution. At imag(z)=0.75i, it is visually the same, and convergence gets better as imag(z) increases, as defined by a 1- cyclic scaling function that goes to a constant as imag(z) increases. - Sheldon Hi Sheldon - I've still no real answer to your questions. However one more observation might lead me into that direction. Using the 64x64-Carlemanmatrix I got the impression that the profile of the eigenvalues tend to something known: possibly, with the index k they approximate to some u^(k^2), and with the index running from -infinty to +infinity; and this reminds me then much of your introduction of a theta-series into the implementation of the Kneser-solution. The problem that I cannot provide a true implementation of a Schröder-function and of its inverse, and thus no true sexp and slog, should be better characterized in the following way: In the regular tetration we generate a triangular Carleman-matrix, say C. Diagonalizing is exact and more important, constant for arbitrary size of the matrix involved. Then we have C = M * D * W where D contains in its diagonal the consecutive powers of the multiplier u. M and W are automatically of the Carleman-type, thus a proper Schröderfunction s(x) can be built from the coefficients of the second column of M. The inverse of the Schröderfunction, say "si(x)" can be built by the second column of W and the consecutive powers of (s(x)*u) - this is just the implementation of an ordinary power series. With the polynomial-method we do initially the same: we diagonalize the matrix C = M * D * W But now neither M,nor W nor D are of the Carleman type, so we must evaluate each column of M, getting a set of coefficients (not consecutive powers), then D has a set of coefficients which seem to be unrelated with each other, and the same is true with W. So we dont have a schröderfunction and also not its logarithm the slog() and we must evaluate the full matrix-product over all columns of W,D and the second column of W. Perhaps there is some finetuning possible though. To the other question: here is a quick&dirty-version of a powerseries in h, which should give the h'th iterate starting from z0=0: f(h) = 0.938382809828*h - 0.167828379563*h^2 + 0.287374412061*h^3 - 0.151317834929*h^4 + 0.152072891321*h^5 - 0.115906539199*h^6 + 0.104252971656*h^7 - 0.0896484652321*h^8 + 0.0804335682514*h^9 - 0.0722083698851*h^10 + 0.0657781099848*h^11 - 0.0603034448582*h^12 + 0.0557107445178*h^13 - 0.0517589491520*h^14 + 0.0483386436954*h^15 - 0.0453431498049*h^16 + 0.0426994261734*h^17 - 0.0403475539535*h^18 + 0.0382412646892*h^19 - 0.0363431568004*h^20 + 0.0346230698175*h^21 - 0.0330562751755*h^22 + 0.0316223524107*h^23 - 0.0303042715741*h^24 + 0.0290877202845*h^25 - 0.0279605769637*h^26 + 0.0269125034199*h^27 - 0.0259346231153*h^28 + 0.0250192655171*h^29 - 0.0241597604217*h^30 + 0.0233502707006*h^31 - 0.0225856544388*h^32 + 0.0218613494467*h^33 - 0.0211732744878*h^34 + 0.0205177425741*h^35 - 0.0198913824642*h^36 + 0.0192910652121*h^37 - 0.0187138333754*h^38 + 0.0181568314451*h^39 - 0.0176172372736*h^40 + 0.0170921958071*h^41 - 0.0165787582106*h^42 + 0.0160738313658*h^43 - 0.0155741444362*h^44 + 0.0150762403807*h^45 - 0.0145765005325*h^46 + 0.0140712092755*h^47 - 0.0135566632029*h^48 + 0.0130293249244*h^49 - 0.0124860162007*h^50 + 0.0119241389267*h^51 - 0.0113419065535*h^52 + 0.0107385638363*h^53 - 0.0101145703178*h^54 + 0.00947172342934*h^55 - 0.00881320086624*h^56 + 0.00814350875574*h^57 - 0.00746833136793*h^58 + 0.00679428854523*h^59 - 0.00612861721557*h^60 + 0.00547880187039*h^61 - 0.00485218452897*h^62 + 0.00425558671715*h^63 - 0.00369497416472*h^64 + O(h^65) Here the same for start at z0=1: f(h) = 1.00000000000 + 1.30087612467*h + 0.613490605591*h^2 + 0.462613730384*h^3 + 0.258026678269*h^4 + 0.163196550177*h^5 + 0.0896232963846*h^6 + 0.0521088351004*h^7 + 0.0278728768121*h^8 + 0.0153988549222*h^9 + 0.00803787843644*h^10 + 0.00428567564173*h^11 + 0.00218991589639*h^12 + 0.00113674868744*h^13 + 0.000570258372500*h^14 + 0.000289775759114*h^15 + 0.000143052447222*h^16 + 0.0000714303563040*h^17 + 0.0000347673520279*h^18 + 0.0000171062518351*h^19 + 0.00000822180736115*h^20 + 0.00000399449536057*h^21 + 0.00000189817814974*h^22 + 0.000000912157817172*h^23 + 0.000000428985593627*h^24 + 0.000000204179146341*h^25 + 0.0000000951111473740*h^26 + 0.0000000448892717431*h^27 + 0.0000000207246449571*h^28 + 0.00000000970923382052*h^29 + 0.00000000444495348205*h^30 + 0.00000000206897297403*h^31 + 0.000000000939569121455*h^32 + 0.000000000434896014592*h^33 + 1.95950745547 E-10*h^34 + 9.02701746055 E-11*h^35 + 4.03579535562 E-11*h^36 + 1.85202423681 E-11*h^37 + 8.21532589062 E-12*h^38 + 3.75895249924 E-12*h^39 + 1.65398790921 E-12*h^40 + 7.55348988152 E-13*h^41 + 3.29536565950 E-13*h^42 + 1.50386648676 E-13*h^43 + 6.50048867954 E-14*h^44 + 2.96864069036 E-14*h^45 + 1.27005340533 E-14*h^46 + 5.81424087541 E-15*h^47 + 2.45836244673 E-15*h^48 + 1.13062762175 E-15*h^49 + 4.71495264346 E-16*h^50 + 2.18452094165 E-16*h^51 + 8.96002942713 E-17*h^52 + 4.19710010287 E-17*h^53 + 1.68674972326 E-17*h^54 + 8.02580312930 E-18*h^55 + 3.14409639911 E-18*h^56 + 1.52906227353 E-18*h^57 + 5.79803950799 E-19*h^58 + 2.90599482712 E-19*h^59 + 1.05635889369 E-19*h^60 + 5.51749837772 E-20*h^61 + 1.89731889651 E-20*h^62 + 1.04844959488 E-20*h^63 + 3.34780766727 E-21*h^64 + O(h^65) No guarantee that this is correct; I just let Pari/GP expand the symbolic expression of the indicated computation with fixed x= and h indeterminate. Gottfried Gottfried Helms, Kassel sheldonison Long Time Fellow Posts: 684 Threads: 24 Joined: Oct 2008 10/16/2013, 04:12 PM (This post was last modified: 10/16/2013, 04:50 PM by sheldonison.) (10/16/2013, 12:54 PM)Gottfried Wrote: .... Here the same for start at z0=1: f(h) = 1.00000000000 + 1.30087612467*h + 0.613490605591*h^2 + 0.462613730384*h^3 + 0.258026678269*h^4 + 0.163196550177*h^5 + 0.0896232963846*h^6 + 0.0521088351004*h^7 + 0.0278728768121*h^8 + 0.0153988549222*h^9 + 0.00803787843644*h^10 + 0.00428567564173*h^11 + 0.00218991589639*h^12 + 0.00113674868744*h^13 + 0.000570258372500*h^14 + 0.000289775759114*h^15 + 0.000143052447222*h^16 + 0.0000714303563040*h^17 + 0.0000347673520279*h^18 + 0.0000171062518351*h^19 + 0.00000822180736115*h^20 + 0.00000399449536057*h^21 + 0.00000189817814974*h^22 + 0.000000912157817172*h^23 + 0.000000428985593627*h^24 + 0.000000204179146341*h^25 + 0.0000000951111473740*h^26 + 0.0000000448892717431*h^27 + 0.0000000207246449571*h^28 + 0.00000000970923382052*h^29 + 0.00000000444495348205*h^30 + 0.00000000206897297403*h^31 + 0.000000000939569121455*h^32 + 0.000000000434896014592*h^33 + 1.95950745547 E-10*h^34 + 9.02701746055 E-11*h^35 + 4.03579535562 E-11*h^36 + 1.85202423681 E-11*h^37 + 8.21532589062 E-12*h^38 + 3.75895249924 E-12*h^39 + 1.65398790921 E-12*h^40 + 7.55348988152 E-13*h^41 + 3.29536565950 E-13*h^42 + 1.50386648676 E-13*h^43 + 6.50048867954 E-14*h^44 + 2.96864069036 E-14*h^45 + 1.27005340533 E-14*h^46 + 5.81424087541 E-15*h^47 + 2.45836244673 E-15*h^48 + 1.13062762175 E-15*h^49 + 4.71495264346 E-16*h^50 + 2.18452094165 E-16*h^51 + 8.96002942713 E-17*h^52 + 4.19710010287 E-17*h^53 + 1.68674972326 E-17*h^54 + 8.02580312930 E-18*h^55 + 3.14409639911 E-18*h^56 + 1.52906227353 E-18*h^57 + 5.79803950799 E-19*h^58 + 2.90599482712 E-19*h^59 + 1.05635889369 E-19*h^60 + 5.51749837772 E-20*h^61 + 1.89731889651 E-20*h^62 + 1.04844959488 E-20*h^63 + 3.34780766727 E-21*h^64 + O(h^65) No guarantee that this is correct; I just let Pari/GP expand the symbolic expression of the indicated computation with fixed x= and h indeterminate. GottfriedThe difference between your taylor series, and the Kneser solution taylor series is reasonably small. All the coefficients differ by less than 2.5^10-6. To me, it does indeed look like the Kneser solution, both in the complex plane and the real axis. Of course, there is the limit in accuracy to 10^-6, which makes it difficult to say if it really is the same function in the limit, but this is much more accurate than some of the other non-equivalent solutions, like the base change solution, or Tommy's 2sinh solution. I don't have the time right now, to dig into your algorithm to understand why it might be the same as the Kneser approach. - Sheldon Code:differenece at sexp(0) where sexp(z)=1 {difference=         0 +x^ 1*  0.00000182148778692911855 +x^ 2*  0.00000236395128074178906 +x^ 3*  0.0000000364681675375429581 +x^ 4* -0.000000488269140029040618 +x^ 5* -0.000000715322531855772069 +x^ 6* -0.000000894405252808757919 +x^ 7* -0.000000604527450774569225 +x^ 8* -0.000000566747124818283086 +x^ 9* -0.000000325020053083984524 +x^10* -0.000000262436257811905389 +x^11* -0.000000138691634039540176 +x^12* -0.000000101836267062431268 } {kneser=         1.00000000000000000 +x^ 1*  1.30087430318221307 +x^ 2*  0.613488241639719258 +x^ 3*  0.462613693915832462 +x^ 4*  0.258027166538140029 +x^ 5*  0.163197265499531856 +x^ 6*  0.0896241907898528088 +x^ 7*  0.0521094396278507746 +x^ 8*  0.0278734435592248183 +x^ 9*  0.0153991799422530840 +x^10*  0.00803814087269781191 +x^11*  0.00428581433336403954 +x^12*  0.00219001773265706243 } {gottfried=         1.00000000000000000 +x^ 1*  1.30087612467000000 +x^ 2*  0.613490605591000000 +x^ 3*  0.462613730384000000 +x^ 4*  0.258026678269000000 +x^ 5*  0.163196550177000000 +x^ 6*  0.0896232963846000000 +x^ 7*  0.0521088351004000000 +x^ 8*  0.0278728768121000000 +x^ 9*  0.0153988549222000000 +x^10*  0.00803787843644000000 +x^11*  0.00428567564173000000 +x^12*  0.00218991589639000000 } I also looked at your Taylor series at 0, which is accurate to 10^-4, so it isn't nearly as accurate. To some extent, this might be because the inherent radius of converegence around sexp(-1)=0 is radius=1, so one must be more careful go get an accurate Taylor series. At sexp(0)=1, the radius of convergence is 2, which is sometimes easier to work with. - Sheldon Code:differnce at sexp(-1) where sexp(z)=0 {differncem1=         0 +x^ 1*  0.000000356817567666656170 +x^ 2* -0.00000779165247553834254 +x^ 3*  0.0000223778203088194483 +x^ 4* -0.0000392692063114664084 +x^ 5*  0.0000588782841305703862 +x^ 6* -0.0000798939836470416862 +x^ 7*  0.000101728675963082681 +x^ 8* -0.000123762693382960570 +x^ 9*  0.000145474277203847197 +x^10* -0.000166438511665979836 +x^11*  0.000186279179283386476 +x^12* -0.000204687037326049608 } Gottfried Ultimate Fellow Posts: 853 Threads: 126 Joined: Aug 2007 10/16/2013, 05:07 PM (10/16/2013, 04:12 PM)sheldonison Wrote: The difference between your taylor series, and the Kneser solution taylor series is reasonably small. All the coefficients differ by less than 2.5^10-6. To me, it does indeed look like the Kneser solution, both in the complex plane and the real axis. (...)Well, this is going to become ironic somehow... That "polynomial interpolation" was my very first and naive approach to the tetration (see my first messages here in the board) and then I felt its model was too unspecific and did a big exploration until I arrived at the regular tetration with the Carleman-matrix (which I called "Matrixoperator" not knowing they are already well studied) including the series-recentering towards the fixpoint and then eigendecomposition - just to come back to the beginning and meet ol' Hellmuth Kneser there... Sometimes things go strange... Gottfried Gottfried Helms, Kassel tommy1729 Ultimate Fellow Posts: 1,675 Threads: 368 Joined: Feb 2009 10/22/2013, 12:17 PM I thought the Kneser method was a riemann mapping from a piece of the brown curve of Gottfried's first 2 pics onto the positive real axis. But those pics show selfcrossing ! Hence what did I miss about the Kneser method ? Of course those selfcrossings can be undone by another mapping but then it seems arbitrary and I wonder how to keep the property of analytic ? Hmm it seems possible to get both by polygon interpolation of the points then map the polygon by riemann mapping to the real line and then sort out the selfcrossing by finding the crossings. But that seems kind of sloppy. Gottfried Ultimate Fellow Posts: 853 Threads: 126 Joined: Aug 2007 10/22/2013, 01:53 PM (10/22/2013, 12:17 PM)tommy1729 Wrote: I thought the Kneser method was a riemann mapping from a piece of the brown curve of Gottfried's first 2 pics onto the positive real axis. But those pics show selfcrossing ! Hence what did I miss about the Kneser method ?Hmm, unfortunately I did never understand in which way some mapping -be it Riemann or something else- is introduced into the mathematical model or even only into the computations of values or of the coefficients of the power series for the regular tetration. (I only found lots of web-pages which focus on *the proof* of the mapping theorem in this or that way). So sorry, I cannot be of help here. Gottfried Gottfried Helms, Kassel Gottfried Ultimate Fellow Posts: 853 Threads: 126 Joined: Aug 2007 10/27/2013, 11:40 PM (This post was last modified: 10/27/2013, 11:49 PM by Gottfried.) Here ist a picture which shows the mapping of the small positive part of the imaginary axis in heights of h=1/20 when computed by the "polynomial method" with the diagonalization of the 64x64 Carlemanmatrix. The coordinates of the initial linesegment are computed by the 21 coordinates at the imaginary axis between 0 and 0.5 I. To avoid logarithms of zero this is a bit translated by adding 1e-4*I to the coordinates. Then 20 iterations with height of 1/20 are computed for that whole initial line. This gives the red skewed rectangle in the rough area (0+0I,0+0.5I,1,1+0.5*I) Then that matrix of coordinates is completely mapped by natural iterations of the powertower with base 4. The whole segment becomes more and more distorted and shrinks when iterated to the complex fixpoint. What is especially interesting me are the "eyes" /the whitespace in the inner spiral - and what about of regions of overlap in there if my initial linesegment where longer, say up to 0.8*I. This direction would be related by complex iteration heights - but I've not yet reliable computations of that heights. [attachment=1016] Attached Files Image(s)     Gottfried Helms, Kassel sheldonison Long Time Fellow Posts: 684 Threads: 24 Joined: Oct 2008 10/28/2013, 04:17 PM (This post was last modified: 10/28/2013, 05:20 PM by sheldonison.) (10/27/2013, 11:40 PM)Gottfried Wrote: Here ist a picture which shows the mapping of the small positive part of the imaginary axis .... of the powertower with base 4. The whole segment becomes more and more distorted and shrinks when iterated to the complex fixpoint. What is especially interesting me are the "eyes" /the whitespace in the inner spiral - and what about of regions of overlap in there if my initial linesegment where longer, say up to 0.8*I. This direction would be related by complex iteration heights - but I've not yet reliable computations of that heights.http://math.eretrandre.org/tetrationforu...hp?tid=358 is a link to Jay's post on the Chi-Star, which is the distorted part of the limiting behavior of your graph as well. To get the Chi-Star, one has to take the regular Schroeder function, developed from the complex fixed point, of the real axis of the sexp(z) solution. Then the pattern repeats, scaled. And then each of the "eyes" would extend all the way to infinity in a beautiful complicated recursive pattern. Jay's post also shows the relationship with the chi-star and the region which gets Riemann mapped in Kneser's construction, which Tommy asked about. - Sheldon tommy1729 Ultimate Fellow Posts: 1,675 Threads: 368 Joined: Feb 2009 10/28/2013, 11:11 PM Ok some guts is needed to admit I do not fully understand and to say I find some things not perfectly well explained. In particular because it sounds stupid and ungrateful , which I am not. But it needs to be done. For Kneser's solution alot of attention is going to the Riemann mapping but the " a priori " is not clear to me. Maybe Im getting old and I am asking question that I have asked before or understood before so plz forgive me if so. From my experience it is best to ask very specific questions so I will point to the post I find most confusing. But first a silly question probably , what I will probably know right after I asked :p About the schroeder equation F( f(x) ) = q F(x). Let c be the fixpoint of f(x). Now it appears to me that F© must be either 0 or infinite. What usefull stuff can be said if F© = oo ? Or is that completely useless ? Second , Why do we prefer f ' © = 1 ? I assume it is ONLY for the easy solvability of the Taylor series or limit formula for the " principal " schroeder function. Having probably answered those questions somewhat myself , let continue with the MAIN question(s) and the principal schroeder function. Since we have f © = 0 we thus have a Taylor series expanded at c. However there is a limit radius of convergence. And the real line is not included in the radius , so the trouble begins. I was only able to find ONE POST adressing how to continue before the Riemann mapping ( all the others seemed to be copied or linked to that " mother post " ) It is still not clear to me what exactlty is mapped , what happened to the singularities and if all that does not loose the property of analyticity. Also Im not sure what kind of " solution " we are suppose to end up with ?? A sexp that has no singularities for Re > 0 ? What properties are claimed for the Kneser solution ? Is it only the property of sexp being analytic near the real line for Re > 0 ? The post that failed to enlighten me was this one : - with respect to the poster of course - http://math.eretrandre.org/tetrationforu...hp?tid=213 POST NR 3 It is said : we analyticly continue to ... HOW ? What happened to the singularities and limited radius ? If you use Taylor series you CANNOT have a function that converges on the entire upper plane ; the Taylor series ALWAYS converges in a circle !!? It is not said how the continuation is done , how we know it is possible , what series expansion we end up with etc etc So what to make of that ? I note that mapping a singularity or pole with exp or ln remains a problem ? Then there follows a claim of simply connected which I find a bit handwaving ?? And what if it contains singularities ?? How is this different from Gottfriend's brown curve ? I also note that the Riemann mapping may not change the functional equation. Those 3 pics do not explain all that and perhaps a longer post should have been made. With respect to the efforts though. I hope I have sketched what I believe confuses most people about Kneser's method. regards tommy1729 tommy1729 Ultimate Fellow Posts: 1,675 Threads: 368 Joined: Feb 2009 10/28/2013, 11:29 PM The only thing I can come up with is that : 1) we simply take the principal schroeder function near the fixpoint c. 2) in that domain we use analytic continuation ( monodromy ) so that by small radiuses recentered we can reach any value in the upper plane. 3) In that upper plane we find ( after many continuations ) the values equalling the reals between 0 and 1. ( and those are connected ) ( for reasons yet to be explained !) 4) the functional equation still holds after the analytic continuation ( for reasons yet to be explained ) 5) We do a Riemann mapping from those values ( reals between 0 and 1) onto the reals between 0 till 1. (we connect 1 to 1) 6) in 5) the functional equation still holds ( again for reasons yet to be explained since we are outside the radius of convergeance of c and did a mapping ! ) 7) by swcharz reflection and analytic continuation we our desired real to real schroeder function. by using log we get the desired abel function. 9) take the functional inverse of the abel function ( series reversion maybe ). 10) we have sexp analytic near the positive real line. I probably got it wrong or didnt I ? And if I got It right , there is still alot to be explained !! regards tommy1729 tommy1729 Ultimate Fellow Posts: 1,675 Threads: 368 Joined: Feb 2009 10/28/2013, 11:32 PM Another detail is that we need to show the schroeder function HAS analytic continuation in the first place , in other words , no essential singularities and no natural boundaries ! But maybe that is the easy part. regards tommy1729 « Next Oldest | Next Newest »

 Possibly Related Threads… Thread Author Replies Views Last Post Continuous Hyper Bouncing Factorial Catullus 9 117 08/15/2022, 07:54 AM Last Post: JmsNxn Qs on extension of continuous iterations from analytic functs to non-analytic Leo.W 17 819 08/10/2022, 11:34 PM Last Post: JmsNxn Unifying continuous and discrete physics Daniel 0 39 07/31/2022, 01:26 PM Last Post: Daniel A related discussion on interpolation: factorial and gamma-function Gottfried 9 17,758 07/10/2022, 06:23 AM Last Post: Gottfried Question about tetration methods Daniel 17 699 06/22/2022, 11:27 PM Last Post: tommy1729 Small research update MphLee 2 1,104 10/26/2021, 12:22 AM Last Post: MphLee My interpolation method [2020] tommy1729 1 3,244 02/20/2020, 08:40 PM Last Post: tommy1729 Possible continuous extension of tetration to the reals Dasedes 0 3,126 10/10/2016, 04:57 AM Last Post: Dasedes Tribonacci interpolation ? tommy1729 0 3,712 09/08/2014, 10:37 AM Last Post: tommy1729 How many methods have this property ? tommy1729 1 4,928 05/22/2014, 04:56 PM Last Post: sheldonison

Users browsing this thread: 2 Guest(s)


text:
# Count the Deliveries

National High School Prog...
Limits 2s, 512 MB

Lazim has recently decided to open a pizza restaurant. His restaurant’s speciality is that they can deliver a large number of pizzas on demand. For this, customers need to tell their order amounts beforehand. After performing many deliveries, Lazim wants to know how many pizzas he has sent to each customer. And it is your job to figure that out.

Lazim has given you all of his customer records. Initially, all customers have set the count of pizza they want to be 0. Then the events were recorded sequentially. There are two types of records:

1. $1$ $l$ $r$ $k$: meaning that for each $l \leq i \leq r$, the $i$ th customer increases their current order amount by $k$ meaning that, if he previously had order amount set to $x$ then his new order amount is $x+k$

2. $2$ $l$ $r$ $k$ : meaning that for each $l \leq i \leq r$ , the $i$th customer ordered $k$ times with his/her order amount. So if at that time his/her order was $x$, then they ordered $k$ times and got $k \cdot x$ pizzas delivered.

You have seen all the records, now for each customer $1, \cdots, n$ you have to determine how many pizzas Lazim delivered to them in total.

## Input

First line of the input will contain an integer $T$, the number of testcases.

For each testcase, first two two integers $n$ and $q$ are given in a line, representing the number of customers and number of records. Then $q$ records are given in the next $q$ line. The $i$th record is given as $4$ integers $t$ $l$ $r$ $k$, where $t$ is $1$ or $2$ as described above.

#### constraints

• $1 \leq T \leq 2 \cdot 10^3$

• $1 \leq n, q \leq 10^5$

• $1 \leq t \leq 2$

• $1 \leq l \leq r \leq n$

• $1 \leq k \leq 10^4$

• Sum of $n$ over all testcase $\leq 10^6$

• Sum of $q$ over all testcase $\leq 10^6$

Subtask 1 (5 points) : For all records $l = r$

Subtask 2 (20 points) : For type 1 records $l = r$, type 2 records can have $l \neq r$

Subtask 3 (75 points) : All records can have $l \neq r$

## Output

For each test case, output in a line $n$ integers. The $i$th integer should be the total amount ordered by customer $i$. Note that the answer will fit into 64 bit signed integer.

## Sample

InputOutput
2
5 5
1 2 5 10
1 1 4 5
2 1 3 5
2 1 5 2
2 5 5 1
6 10
1 1 6 5
1 4 5 100
2 1 4 5
1 3 6 1
2 2 5 20
2 1 3 10
1 1 6 50
2 3 4 12
1 2 6 15
2 1 4 5

35 105 105 30 30
350 525 1232 5372 2120 0

In the first test, initially all customers have their order amount set to 0.

1. After first record, customer 2 to 5 increase their order amount by 10. Current order amounts: 0 10 10 10 10

2. After second record, customer 1 to 4 increase their order amount by 5. Current order amounts: 5 15 15 15 10

3. After third record, customer 1 to 3 order 5 times. So customer 1 receives 25 pizzas and customer 2-3 receive 75 pizzas each. Current order amounts: 5 15 15 15 10

4. After fourth record, customer 1 to 5 order 2 times. So customer 1 receives 10 pizzas, customer 2-4 receive 30 pizzas each and customer 5 receives 20 pizza. Current order amounts: 5 15 15 15 10

5. After fifth record, customer 5 orders 1 time. So customer 5 receives 10 pizzas. Current order amounts: 5 15 15 15 10

If you count the deliveries you will see that the customers received 35, 105, 105, 30, 30 pizzas. Note that changing the order amount does not mean delivery, deliveries are performed only during type 2 record. Similarly delivery does not mean change of order amount.

Note that the sample is not considered part of subtask 1 and subtask 2. So for subtask 1 and subtask 2, your code doesn't have to work on the sample.

format: plain


text:
Probability of Grouping boys and girls

10 boys and 2 girls are divided into 3 groups of 4 each. The probability that the girls will be in different groups is?

-
...low?${}{}{}$ – Shahar Aug 28 '14 at 1:08

A simple way is to suppose that person A has been assigned to Group 1. Note that $3$ of the remaining $11$ will be assigned to Group 1. The probability that person B is one of them is $\frac{3}{11}$. So the probability that A and B end up in different groups is $\frac{8}{11}$.

There are more elaborate combinatorial arguments.

Remark: At the request of OP, here is a more complicated argument. Without changing the probabilities, we may assume that the groups are named groups, say Groups 1, 2, and 3.

The number of (equally likely) ways to assign people to named groups is $\frac{12!}{4!4!4!}$. One way of seeing this is that there are $\binom{12}{4}$ ways to decide who goes into Group 1, and for each of these there are $\binom{8}{4}$ ways to decide who goes into Group 2.

Now we could directly count the number of ways to assign A and B to different groups, or do it indirectly by counting the number of ways to assign A and B to the same group. We do the second.

There are $\binom{3}{1}$ ways to choose the common group. For each of these, there are $\binom{10}{2}$ ways to choose the groupmates of A and B. And there are $\binom{8}{4}$ ways to decide on the members of the first unused group, for a total of $\binom{3}{1}\binom{10}{2}\binom{8}{4}$.

Divide by $\frac{12!}{(4!)^3}$ to find the probability A and B end up in the same group. Fairly quickly, the expression simplifies to $\frac{3}{11}$.

-


text:
# What do I need to do to find the stopping time of a decelerating car? [closed]

The question is:

A car can be stopped from initial velocity 84 km/h to rest in 55 meters. Assuming constant acceleration, find the stopping time.

Sorry for my ignorance, but I need to review physics knowledge. Can anyone explain me for this question?

-

## closed as off topic by Qmechanic♦, dmckee♦Jan 2 '12 at 14:30

Questions on Physics Stack Exchange are expected to relate to physics within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

It will always help if you can set out the progress you have made so far on answering the question –  EnergyNumbers Jan 1 '12 at 10:11
@EnergyNumbers: It would help if the problem was actually a well posed one. –  Ron Maimon Jan 1 '12 at 17:50
As written this question seems to fail the concept-not-problem restriction in the FAQ for homework type question, but EnergyNumbers' answer is sufficiently conceptual that I'm minded to leave it open. –  dmckee Jan 2 '12 at 3:41
@dmckee: I think you are right. (One might argue that the question should be closed anyway, to indicate that it is inappropriate by our guidelines and to prevent more answers from being added unless/until it's improved... I'll leave it as your call.) –  David Z Jan 2 '12 at 7:04

## 2 Answers

Well, as the acceleration is constant you can use equations of uniform accelerated motion. Here, you are given with $v_0 =$ initial velocity, $d =$ distance traveled by car before stopping directly, and as the car eventually stops, hence you know the final velocity $v$, which is zero in this case.

Using two equations of motions, (a) $v^2 - v_0^2 = 2 a d$ and (b) $v = v_0 + at$ you can get the formula for time as,

$$t = \frac{2d}{(v+v_0)}$$

Hence, calculate the time taken before stopping.

-
thank you so much –  eureka Jan 2 '12 at 8:58

Acceleration is the change in velocity per unit time. A constant acceleration is specified in the question: that means that the velocity will change by a constant amount, each second. Have a think about what that means, for the shape of the graph of velocity plotted against time. Can you express the area under that curve/line, as a function of its height (initial velocity) and its base length (stopping time)?

Velocity is distance travelled per unit time. So, what is represented by the area under the graph of velocity plotted against time?

Combining all of this, you should now have an expression for total distance travelled, expressed as a function of the initial velocity and the stopping time. And you can manipulate that equation so that stopping time is a function of total distance travelled and initial velocity.

-


text:
# Digital health: a path to validation

## Abstract

Digital health solutions continue to grow in both number and capabilities. Despite these advances, the confidence of the various stakeholders — from patients and clinicians to payers, industry and regulators — in medicine remains quite low. As a result, there is a need for objective, transparent, and standards-based evaluation of digital health products that can bring greater clarity to the digital health marketplace. We believe an approach that is guided by end-user requirements and formal assessment across technical, clinical, usability, and cost domains is one possible solution. For digital health solutions to have greater impact, quality and value must be easier to distinguish. To that end, we review the existing landscape and gaps, highlight the evolving responses and approaches, and detail one pragmatic framework that addresses the current limitations in the marketplace with a path toward implementation.

## Introduction

The concept of digital health continues to evolve. Clinicians and patients should ask: Which solutions are substantiated and which, despite marketing claims, are not? First introduced in 2000 by Seth Frank,1 digital health largely encompassed internet-focused applications and media to improve medical content, commerce, and connectivity. The term digital health has expanded to encompass a much broader set of scientific concepts and technologies, including genomics, artificial intelligence, analytics, wearables, mobile applications, and telemedicine.2 In addition, digital health technologies are being applied much more broadly in medicine to include diagnosis, treatment, clinical decision support, care management, and care delivery. In 2018, the World Health Organization issued a detailed taxonomy of Digital Health, articulating dozens of facets of this expanding space.3

Investment in the digital health sector is enormous, with nearly $6B in funding in 2017, increased from$4.4B in 2016.4 For mobile health applications alone, there exist more than 3,00,000 health apps with more than 200 health apps added daily.5 This highlights the increasingly voluminous and cluttered landscape all healthcare stakeholders—patients, providers, payers, industry, and regulators—must navigate. Their challenge is finding solutions that provide real value.

Currently, no reliable mechanism exists to identify validated digital health solutions. Payers, too, cannot easily identify quality in this crowded field. Regulatory guidance and oversight are limited, with enforcement restricted to companies that make claims out of proportion to the evidence or where application failures might lead to risks to patient safety.6

Oversight frameworks of digital health have been proposed, which mainly focus on patient safety.7 Healthcare needs a robust and transparent validation process for digital health products. All healthcare stakeholders would benefit from a more standardized, objective, rigorous, and transparent process for validation. Specifically, the validation domains would be technical validation (e.g., how accurately does the solution measure what it claims?), clinical validation (e.g., does the solution have any support for improving condition-specific outcomes?), and system validation (e.g., does the solution integrate into patients’ lives, provider workflows, and healthcare systems). A proposed pathway is outlined. A forthcoming pilot study (and publication of a detailed corresponding framework) will contain finer details of the proposed pathway.

## Existing landscape

The rapid advancement and promotion of digital health technologies has produced a unique landscape, characterized by an industry able to rapidly iterate technology, often at the expense of the traditional medical product design, safety testing, and clinical efficacy trials. Prior to the digital and mobile age of health technology, technology development speed was set by manufacturing, distribution, and regulatory considerations, which inherently demanded a slower development cycle. Digital health technologies, however, generally lack these constraints. This enables rapid creation, iteration, and distribution, which incentivize developers to minimize the time to develop design requirements. The minimum necessary verification and validation activities are pursued to ensure correct product fabrication to meet the intended use and end-user needs. Although some digital health products have been rigorously studied to determine clinical effectiveness,8,9 such evaluation is not widespread. This can lead to discrepant and misleading claims, as well as dubious quality.10 For example, a recent evaluation of 280 diabetes mobile applications found only five associated with clinically meaningful improvement and none were of high methodological quality.11 This risk is further compounded by a dearth of well-established value and impact-based business models for digital health, which also leads to faster-paced experimentation. The “fail fast, fail often” mantra espoused by technology startups is frustrated by the confusing regulatory landscape of healthcare. This cultural clash is further exacerbated by the cautious, stepwise, and time-consuming process of healthcare innovation that is grounded in the risk-averse clinical principle of “first, do no harm”.12

The use of health technology is also expanding into areas that are ambiguous from a regulatory perspective. For example, the 21st Century Cures act amended the Federal Food, Drug, and Cosmetic Act to remove certain clinical decision support functionalities from the definition of “medical device”, thus removing, or at least changing, the regulatory oversight responsibilities of these technologies by the Food and Drug Administration (FDA).13 In response, the FDA started pilot projects and published a number of guidance documents to elucidate their position on these topics.14 A representative illustration of the varying regulatory considerations based on clinical risk and technical complexity for digital technologies is shown in Fig. 1. Other Federal Agencies also have a role in regulation of digital health technologies. The Federal Trade Commission (FTC) prohibits deceptive or unfair acts or practices, including false or misleading claims about the safety or performance of digital health technologies. To provide clarity about the regulatory environment for a mobile app developer, the FTC, FDA, Health and Human Services (HHS) Office of the National Coordinator for Health Information technology (ONC), and Office for Civil Rights (OCR) have developed a tool for developers to use to understand what federal laws are applicable to their technology.15

While there remains significant regulatory ambiguity, these efforts represent initial efforts for clarity. There is not yet, however, commensurate attention paid to ensuring products meet target users’ needs. Current indications point to a future where only a fraction of digital health technologies are subject to regulatory review prior to market entry. Many other sophisticated, unproven solutions will continue to proliferate, frustrating end-users looking for a way to improve their well-being or disease self-management. Thus, the onus is shifted to the clinician and patient to identify effective and useful digital health technologies, bearing the risk of ineffective, or even potentially harmful, solutions. The need for new accessible tools to assist in informed decision-making is clear for all domains of the digital health spectrum illustrated in Fig. 1. For high-risk clinical scenarios or complex technologies, the necessity for such a tool is due to inherent concern posed by the technology, and would be useful to augment the FDA’s clearance or approval process. For lower-risk technologies where there is a trend toward lower regulatory oversight, new tools may provide the only independent insight into the performance of a digital health technology for consideration by the clinician and patient end-users.

## Evolving approaches

Initiatives to curate or certify digital health applications trace their roots back to early 2010, some even offering paid accreditation to help users separate “snake oil” from legitimate offerings.16 Several of these activities failed, rapidly overwhelmed by the Herculean task before them.17 Today, promising developments are underway to help better differentiate digital health products. A summary of existing representative resources and approaches are detailed in Table 1. Within industry, the Personal Connected Health Alliance provides design guidance based on the Continua Alliance standards and design model.18 This focuses on personal connected devices, such as weight scales, blood pressure monitors, and glucose meters. The newly formed Xcertia group is creating broad criteria and guidelines specifically for health mobile app curation, but leaves the task of evaluation and validation based on the guidelines to industry participants.19 This approach is in contrast to a notable predecessor of Xcertia, Happtique, a venture-backed company spinoff created by the Greater New York Hospital Association in 2010, which failed to commercialize health app certification. The Xcertia guidelines presently do not include clinical outcomes validation, though others such as NODE. Health and the Digital Therapeutic Alliance are attempting to fill this gap.

The United Kingdom’s National Health Service (NHS) currently hosts a Beta site Digital Apps Library, in which it lists “NHS approved” 70 + medical apps across an array of medical conditions, including cancer, chronic obstructive pulmonary disease, dementia, diabetes, mental health, and pregnancy.20 These aim to reflect high-quality, safe, effective, accessible, and usable apps for which published medical evidence supports their use. Other listed apps are “Being Tested in the NHS,” which reflect preliminary approval and current research within the NHS to determine clinical effectiveness. The NHS specifically solicits from industry app development for particular areas of health, including maternity, social care, chronic conditions, cancer, and mental health. Broad criteria for approval, defined by NHS Digital and National Institute for Health and Care Excellence, pertain to clinical effectiveness, regulatory approval, clinical safety, privacy & confidentiality, security, usability & accessibility, interoperability, technical stability, and change management. A host of additional app curation sites also exist,21,22 with a varying range of analytic methods compared with the NHS.

These initiatives are relatively new with overlapping standards. They will likely advance the field, but may not provide sufficiently clear and robust direction for patients and providers on the most effective products that meet specific requirements to best integrate into a particular healthcare context. In addition, there is a lack of objective, comprehensive, transparent, and standards-based evaluation, which also limits confidence and practical application of existing approaches.23 A Digital Health Scorecard—a multi-stakeholder approach that objectively and rigorously evaluates solutions—is needed to provide the healthcare marketplace with greater insight, clarity, and guidance.

Outside digital health, there are analogous consumer product evaluation organizations, such as UL (formerly Underwriters Laboratory)24 and Consumer Reports,25 which provide potentially useful models for digital health. UL focuses on safety-related topics by certifying product compliance with international standards. UL does not, however, ensure a product meets end-user needs. Although safety is one end-user need, needs extend beyond safety, including portability, interoperability, and usability. Consumer Reports, on the other hand, represents the opinions of objective reviewers regarding the ability of a product to serve a particular function, which is end-user focused—is the product right for the job? Together, UL and Consumer Reports evaluations steer product developers toward the development of solutions that best serve end users. There are two important differences between UL and Consumer Reports. First, the standards UL certifies are well-known to the product developers. Second, UL conducts pre-market certification testing. In contrast, the requirements Consumer Reports uses as the basis for its evaluations are elicited post market and are not well documented or disclosed to the developer pre-market—the developer must anticipate end-user needs and requirements and therefore hope to “get it right.” Our proposed Digital Health Scorecard is based upon a hybrid approach that proactively defines requirements and standards for digital health products; transparently discloses them; and objectively evaluates and reports to industry and the public.

## Need for requirements-driven approach

In aviation or motor vehicle manufacturing, there is a straightforward path from a perceived market need to product commercialization (Fig. 2, top box). The product lifecycle begins with establishing requirements. Here, teams of stakeholders define the features, functionality, and performance needs for the product—“the product shall do X” and “the product shall not do Y.” (Requirements may contain great detail on what the system should not do.)

An aviation requirement, for example, might state “the airplane shall provide seating for no more than six people.” Further context for that requirement might include nominal or maximum size and weight of those adults. Furthermore, requirements could dictate standards, such as electrical or physical safety standards. Importantly, these requirements and standards are thoroughly documented and may even lead to initial prototypes, which may be virtual simulations or physical models of the eventual end product to aid in refining the design ensuring it meets the specified requirements. The crucial “Test and Evaluate” step focuses on verification and validation. The former term determines whether the product was designed and developed in accordance with the upfront requirements (e.g., does the plane accommodate six passengers?), while the latter determines whether the product meets the end-user’s requirements (e.g., should it have been designed to carry more people?).

Presently, much of the digital health industry lacks this rigor, including several steps along the traditional product development cycle (Fig. 2, dashed boxes). The current digital health product lifecycle often focuses on high-level requirements, if at all, which limits what can be verified or validated. These fundamental elements of the product development process remain essential even in today’s world of agile development, and continuous cloud-based product deployments. We believe a Digital Health Scorecard will promote requirements-driven development to the benefit of all stakeholders.

Specifically, in our proposed lifecycle (Fig. 2), an “independent evaluation” phase provides a role, both during development and post-market entry. In this approach, an objective independent entity (or authorized entities) undertake the evaluation of digital health pre-market products emerging from developers. The independent evaluation would address both verification and validation and would be based upon a set of well-defined (i.e., measurable, concise, unambiguous) requirements. Developers can use feedback from the Digital Health Scorecard to refine existing products or create new ones. The broader marketplace could use the Scorecard to make informed decisions regarding which products are most applicable for the intended use and which products perform best.

## Components of a digital health scorecard

The development of requirements will vary across types of digital health solutions based on functionality (diagnostics, monitoring, care coordination, etc.), which can also be modeled from other industry approaches. It is critical to incorporate the preferences of the clinicians and patients impacted by the digital health solution into the requirement development process. Once requirements are established, the proposed framework that could form the basis for evaluation includes the following domains: technical, clinical, usability, and cost (Fig. 3).

### Technical

Technical validation is the most traditional type of evaluation in product testing. Does the solution actually perform to its self-proclaimed functionality with accuracy and precision? For example, how accurately and reliably does a wearable measure heart rate compared with a gold standard? Other elements of technical validation could also include security and interoperability assessments. Applications that claim to perform the functions of established medical devices, such as those reflecting biological processes like heart rate, blood pressure, or respiratory rate, should be able to demonstrate equivalence according to rigorous standards set for other non-smartphone based novel devices.26 System failure and redundancy must also be considered—what happens if a digital health system degrades over time as phone camera lenses become scratched or occluded? Is there a need for back-end monitoring of user engagement or daily calibration to ensure appropriate system performance? Do certain processors or sensors fail to meet stringent minimum standards required for reliable system outputs?

A system architecture, the sum of structure, behavior, and components of a technology, has unique considerations in digital health. Developers must consider the privacy and security requirements of handling patient data that may be confidential and even linked to larger electronic health record systems. Robust, enterprise architecture standards exist to guide developers on issues, such as the levels of encryption and user authentication necessary to safeguard patient information. This requirement may vary with the degree of inherent confidentiality of the health condition in focus— ranging from low, when dealing with step-counters or accelerometers—to high if managing a socially stigmatized disease or storing test results.

### Clinical

Clinical validation to demonstrate efficacy is generally well understood and considered vitally necessary in the context of traditional clinical or translational research. However, analogous studies for digital health products is uncommon.27 This gap may be due in part to the lack of clinical subject-matter experts engaged in the digital health product development.28 Regardless of what part of the continuum of care (prevention, detection, and management) the product addresses, a validation study must compare it to relevant clinical gold standards. Particularly for studies aiming to demonstrate the clinical impact of the a product, these may take the form of accepted care quality metrics, such as measures of clinical outcomes (e.g., presence of disease or complications, clinical functional scores) and process (e.g., laboratory values, adherence to treatment guidelines).

A digital health product that aims to prevent diabetes mellitus would be measured by standard clinical quality measures, such as clinically validated disease diagnostic criteria,29 glycemic control, or diabetes-specific complications like stroke and retinal disease.30 This is important not only to ensure that content is based on current state-of-the-art evidence and guidelines but even to assure users that simple digital interventions, such as behavior-modification applications leverage and incorporate decades of proven, efficacious strategies.

An integral validation step is standardized and critical appraisal of any existing evidence (e.g., an approximation of the rigorous GRADE system31) to support any clinical claims made by the product or solution. Existing digital health review resources may provide subjective assessments of the quality of clinical evidence by technical experts, but generally do not provide systematic and objective analysis.

More advanced validation efforts would require external testing within a simulated or actual trial settings to determine if results can be duplicated. Furthermore, such testing would determine how the product performs across the relevant provider systems, clinical settings, and integrated technologies, in which it is likely to be deployed. For example, the data that flows from an app that monitors cardiac function should actually assess the intended cardiac measure or function, assess it in the targeted population (e.g., congestive heart failure), and be accessible to the clinics and hospitals relevant to the target patient population. The data must flow across emergency, intensive care, and ambulatory settings to electronic health records, provider alert systems, and ambulances of these hospital systems. Without meeting such system requirements, deployment of such an app, even if shown to be clinically effective in a research setting, may have no meaning in the real healthcare system for patients.

An added consideration for “prescription-strength” digital health applications may involve post-market surveillance (PMS), as it is required for most drugs and medical devices.32 Often, pre-release clinical studies are not powered to detect rare, but serious, potential device failures which may cause unintended harm to users. Currently, the FDA monitors reports of device and drug adverse events and may require PMS to clarify possible adverse events associated with a device—or verify that efficacy of a device persists in the “real world”, especially if clinical tests used a surrogate outcome for the purposes of expediency.33

### Usability

Formal usability assessment of traditional healthcare goods and services (e.g., pharmaceuticals, procedures, and treatment plans) is frequently embedded within the regulatory and patient experience pathways that lead to their development. Similarly, usability testing in the setting of medical devices is common (from a clinician/operator perspective) due to regulatory requirements, although generally with a safety focus.

When considering digital technology, there is no assurance or protection that the technology will align with user needs or preferences. Usability is arguably among the most important considerations with patient-oriented mobile- and digital-based solutions. These technologies are frequently literally in the hands of patients and consequently demand a more patient-centered approach to usability. Existing digital health qualitative reviews address only some aspects of usability. All stakeholders would benefit from a standardized approach, unlike the status quo, which is often ad hoc, qualitative, or dependent on the volume of reviews.34

Digital health apps must be easy to use for their intended purpose, require minimal effort to complete tasks, have minimal data entry burden, and allow the user to control preferences when appropriate (e.g., notifications). Since systems can be designed for users with different requirements (e.g., impaired vision, motor deficits, cognitive dysfunction), design considerations must reflect the target user-audience.

The World Wide Web Consortium has summarized a user-centered design process (UCD),35 which takes into account multiple frameworks and mirror some elements of the International Organization for Standardization’s multi-part standard, ISO 9421.36 The key objectives outlined in this standard are applicable to the evaluation of digital health applications: the solution should be useful in helping users achieve their goals, effective (i.e., producing results with minimal user error), learnable (i.e., easy and intuitive to use), and likeable (i.e., enjoyable to use). These considerations, not surprisingly, play an important role in patient engagement—an often neglected, yet essential aspect of digital health; having a unused medical device is tantamount to not having one at all.

At a minimum, a best-practice evaluation framework should be considered,37,38 but these frameworks establish a lowest common denominator, and do not necessarily incorporate the principles of user centered design into the development process. There are multiple efforts underway to codify standards for design principles specifically to digital health solutions, most notably Xcertia and Node.Health. Some criteria are easier to objectively specify than others. For example, criteria such as number of steps required to complete essential tasks, consistency of navigation, visual legibility, and use of recognizable iconography can be objectively developed. More work is needed to formalize subjective aspects of usability, such as utility and user delight and satisfaction. Usability viewed in this way, along with clinical relevance, creates the opportunity to impact patient engagement.

To maximize impact, digital health solutions will likely require clinician input as part of solution development, thereby accounting for UCD on at least two fronts. Just as early electronic health record implementations increased clinician burden by not adequately considering clinician workflow,39 digital health solutions designers need must pay attention to ease of accomplishing the expected tasks.

### Cost

At face value, cost—defined as the price a consumer must pay to gain access—may be an inadequate differentiator of digital health solutions—many are free or low priced, particularly in the mobile app arena. When integrated in a composite assessment, however, true cost may provide greater discrimination of overall value. Here, cost estimation becomes more complex by incorporating broader considerations, such as costs of the technology lifecycle and those to integrate technology into the clinical workflow.

Furthermore, the long-term cost implications from outcomes improvements are also difficult to calculate but should be taken into consideration, leveraging metrics from pharmaceutical and device industries. While determination and attribution of financial benefit derived from mobile health apps is challenging,40 real value may be derived from increased personal health engagement, improved patient–clinician engagement, or patient and clinician satisfaction. New ways of quantifying and measuring these types of attributes will provide a more comprehensive picture overall cost-benefit.

### Global score

In the consumer financial industry, the FICO score represents a global score as an amalgamation of credit information to approximate borrower quality and lending risk.41 It contains five subdomains: payment history, current level of indebtedness, types of credit used, length of credit history, and new credit accounts. Correspondingly, by aggregating the individual domain assessments from the Digital Health Scorecard and contextualizing the degree to which a product satisfies end-user requirements, a composite Global Digital Health Score can be created. As a result, consumers and other users would be provided a high-level synthesis of quality and risk for digital health products.

This aggregate score allows gross initial selection of digital solutions. Individual scores allow finer discrimination of particular products. Such scores also allow digital health companies to identify where improvements are needed and inform stakeholders on what gaps will exist when the products are deployed. The scores could become benchmarks and establish thresholds for particular types of digital solutions. These scores would also need to highlight and prioritize how well the product ultimately met the end-user requirements.

### Challenges

The successful Digital Health Scorecard allows better discrimination of digital health products, but just as important, pushes digital health companies to build impactful products that work for real patients, providers, and healthcare systems. Three main types of barriers (conceptual, financial, and operational) could hinder broad execution of this approach.

### Conceptual challenges

The framework described is one possible approach to characterize the needs in digital health and may not fully reflect the needs of the current marketplace. Our framework is modeled from other industry approaches and needs we perceive for digital health. Given the multi-stakeholder nature of healthcare and varying stakeholder incentives, the best approach to impactful, useful, and integrated digital health products may differ than the one described here. For example, although our approach aims to maximize clinical impact on patients, a payer may be more interested in efficient resource utilization. A provider system may seek products that boost high-reimbursement activities, such as attracting surgical patients or increasing advanced, high-cost imaging utilization. Thus, our proposal may not be practical for or applicable to every permutation within the current fragmented healthcare landscape, in which different stakeholders have different incentives. We believe our approach, however, would promote a requirements-driven, impact-focused digital health landscape. Given the nascent, shifting nature of digital health, the most realistic initial approach to a Digital Health Scorecard implementation is to create a requirement set broad enough to encapsulate concepts important to all products, but not inclusive of so much detail that the requirements are not realistic or relevant.

### Financial challenges

The Digital Health Scorecard concept requires a financially viable business model for implementation and sustainability. Sustainability could be realized if companies saw value in, and thus purchased Digital Health Scorecard reports or accreditation ratings. If patients, providers, or payers also saw value in or demanded these reports and ratings, companies may feel or be required to purchase them. It is conceivable that payers and even hospital, provider, and medical specialty associations would fund the creation of such reports and ratings, particularly as they become more financially incentivized to adopt digital health products that improve outcomes.

### Organizational and operational challenges

From an organizational perspective, unlike aviation and the construction of airplanes, digital health products have no single owner of the requirements. The Federal Aviation Administration and aviation companies, however, can set specific requirements that guide the development of airplanes. In digital health, neither patients, physicians, hospitals, payers, nor governmental regulatory bodies create or abide by standard requirement sets for digital health products. Also, unlike conventional aircraft design, many digital health products and accessories are so new that the desired or optimal requirements may be unknown. This further complicates which stakeholder should take primary ownership of driving requirements. No centralized body exists to serve as a clearinghouse for digital health application feedback or failure reporting. Like digital health products, however, novel aviation products such as drones, face unstandardized requirements without a clear curator of these requirements. For all new product types, relevant stakeholders should develop broad requirements categories relevant to the product and a corresponding scorecard approach that enables a best-practice product development and robust product assessment.

From an operational perspective, the tremendous volume and growth of products presently precludes rigorous evaluations for all products. Thus, a Digital Health Scorecard would likely fail in the current landscape if applied universally. Initially, a pragmatic approach could be applied to select products, such as those relevant to high burden or high-cost conditions, already popular with patients or providers, or with peer-reviewed studies to demonstrate validation, efficacy, or both. In addition, self-initiated industry evaluation may overcome the practical barrier of creating a fully capable Digital Health Scorecard organization that tests and evaluates products. Companies could be successful if a clear Digital Health Scorecard guided them with product development. The Scorecard itself could present an opportunity for a multi-stakeholder consultation to first generate and then periodically update, as refinements emerge with time and experience.

If independent outside assessment of digital health products is to be realized, scaling up assessment to meet the demand of many new products would require a large organization, certification network, and substantial resources. The latter could be accomplished by identifying or building a network of independent, objective organizations that could complete the different domain assessments, while following universal requirements from the Scorecard. Partners could vary by their role: traditional hardware/software testing firms to perform validation assessments, academic institutions to perform clinical studies, and auditing firms to assess cost.

### A way forward

The road to validating digital health will take resources, collaboration, and time. Even if successful, the first iteration of the Digital Health Scorecard will be different than latter versions as the healthcare environment evolves. In particular, a Scorecard approach will be most successful when all stakeholders partake in its construction and all stakeholders’ financial incentives are aligned to outcomes. The first Scorecard version, however, if transparent, rigorous, and pragmatic, would be an important step toward impact-driven digital health products that function in real healthcare settings. We are presently pursuing a small-scale pilot study implementing this approach in granular detail, the results of which will be published upon completion.

We believe there are two non-mutually exclusive initial approaches to the Digital Health Scorecard model. First, governmental regulatory bodies should partner with clinical stakeholders to create a standard set of requirements using the categorical concepts proposed here. The regulatory effort could be driven by one organization, such as the FDA’s Digital Health arm, or a collaboration between varied agencies like the FDA, FTC, the Centers for Medicare & Medicaid Services, and the ISO. This collaboration could produce certifications and ratings, but most importantly, requirements sets that promote the development of digital health products poised to be efficacious for the target patient population and function in a healthcare system with varied stakeholders. We do not expect one regulatory body to have the bandwidth, resources, or expertise to take this on alone.

Second, a provider healthcare or hospital system (or collection of systems) could lead to the development and adoption of a Digital Health Scorecard. Our preference is for a hybrid approach in which leading hospital systems partners with one or more of the aforementioned regulatory bodies, including the FDA, to lead a requirements-driven Scorecard approach. This system would not only lay out the requirements for digital health products that enter it, but only accept products that achieved high marks for each category of assessment. An existing healthcare system with enough patient volume could have ample market clout to influence the development of digital health products. Further, healthcare systems could collaborate to create an even more influential Scorecard model of care that drives requirements and product development across larger geographic regions and patient populations.

Although many large healthcare systems have sufficient market influence to drive this change, most are not nimble enough to do so. For example, many leading healthcare systems remain tied to electronic health record technologies, nearly universally disparaged by end-user practitioners and healthcare leaders.42 Furthermore, although many such systems desire to implement digital health and telemedicine care models, they largely represent a small fraction of clinical care.

The healthcare environment is evolving and converging with the entrance of non-traditional healthcare players, such as the CVS-Aetna partnership43 and the nascent Amazon–JP Morgan Chase–Berkshire Hathaway collaboration.44 Here, healthcare systems unconstrained by typical barriers to innovate are perhaps more realistic and promising champions of requirement-driven digital health.

As digital health companies have become more prolific and the number and diversity of digital health products has multiplied, the need for requirement-driven product realization and systematic validation has become increasingly important. Patients and providers will benefit from and demand the ability to discriminate clinically meaningful solutions. Payers and investors will need to identify high-value opportunities that ultimately guide reimbursement, investment decisions, and impact-focused care. Given the growing pull from non-industry stakeholders to demand impact-focused, interoperable digital health products, industry will also find utility in demonstrating product quality over product claims. We provide a framework to guide the evolution and successful delivery of validated digital health solutions.

## References

1. 1.

Frank, S. R. Digital health care—the convergence of health care and the Internet. J. Ambul. care Manag. 23, 8–17 (2000).

2. 2.

Rock Health. 2016 Year End Funding Report: A Reality Check for Digital Health. (San Francisco, CA, Rock Health, 2017). https://rockhealth.com/reports/2016-year-end-funding-report-a-reality-check-for-digital-health/.

3. 3.

World Health Organization. Classification of digital health interventions v1. 0: a shared language to describe the uses of digital technology for health. World Health Organization (2018).

4. 4.

Rock Health. 2017 Year End Funding Report: The End of the Beginning of Digital Health. https://rockhealth.com/reports/2017-year-end-funding-report-the-end-of-the-beginning-of-digital-health/ (2018).

5. 5.

IQVIA. IQVIA Institute for Human Data Science Study: Impact of Digital Health Grows as Innovation, Evidence and Adoption of Mobile Health Apps Accelerate. https://www.iqvia.com/newsroom/2017/11/impact-of-digital-health-grows-as-innovation-evidence-and-adoption-of-mobile-health-apps-accelerate/ (2017).

6. 6.

Schoenfeld, A. J., Sehgal, N. J. & Auerbach, A. The challenges of mobile health regulation. JAMA Intern Med. 176, 704–705 (2016).

7. 7.

Lewis, T. L. & Wyatt, J. C. mHealth and mobile medical apps: a framework to assess risk and promote safer use. J. Med. Internet Res. 16, 9 (2014).

8. 8.

Quinn, C. C. et al. WellDoc™ mobile diabetes management randomized controlled trial: change in clinical and behavioral outcomes and patient and physician satisfaction. Diabetes Technol. Ther. 10, 160–168 (2008).

9. 9.

Svendsen, M. T. et al. A smartphone application supporting patients with psoriasis improves adherence to topical treatment: a randomized controlled trial. Br. J. Dermatol. 179, 1062–1071 (2018).

10. 10.

Plante, T. B. et al. Validation of the instant blood pressure smartphone app. JAMA Intern. Med. 176, 700–702 (2016).

11. 11.

Veazie, S. et al. Mobile Applications for Self-Management of Diabetes. Technical Brief No. 31. (Prepared by the Scientific Resource Center under Contract Nos. 290-2012-0004-C and 290-2017-00003-C.) AHRQ Publication No. 18-EHC010-EF (Agency for Healthcare Research and Quality, Rockville, MD, 2018).

12. 12.

Smith, C. M. Origin and uses of primum non nocere—above all, do no harm! J. Clin. Pharmacol. 45, 371–377 (2015).

13. 13.

21st Century Cures Act, H.R. 34, 114th Cong. https://www.congress.gov/114/plaws/publ255/PLAW-114publ255.pdf (2015).

14. 14.

Shuren, J., Patel, B. & Gottlieb, S. FDA regulation of mobile medical apps. JAMA 320, 337–338 (2018).

15. 15.

16. 16.

AI in Healthcare. Happtique Moving Forward with app Certification Program. https://www.aiin.healthcare/topics/connected-care/happtique-moving-forward-app-certification-program (2012).

17. 17.

HIStalk. The Rise and Fall of Happtique, mHealth’s First App Prescribing Platform. http://histalkmobile.com/the-rise-and-fall-of-happtique-mhealths-first-app-prescribing-platform/ (2014).

18. 18.

Personal Connected Health Alliance. Personal Connected Health. http://www.pchalliance.org/ (2017).

19. 19.

Xcertia. mHealth App Guidelines. http://xcertia.org/ (2017).

20. 20.

NHS. NHS Apps Library. https://apps.beta.nhs.uk/ (2018).

21. 21.

Ranked Health. Curated Health Apps and Devices With a Focus on Clinical Relevance, Safety, and Efficacy. http://www.rankedhealth.com/ (2018).

22. 22.

Boudreaux, E. D. et al. Evaluating and selecting mobile health apps: strategies for healthcare providers and healthcare organizations. Transl. Behav. Med. 4, 363–371 (2014).

23. 23.

Boulos, M. N., Brewer, A. C., Karimkhani, C., Buller, D. B. & Dellavalle, R. P. Mobile medical and health apps: state of the art, concerns, regulatory control and certification. Online J. public health Inform. 5, 229 (2014).

24. 24.

25. 25.

26. 26.

Sharman, J. E. et al. Validation of non-invasive central blood pressure devices: ARTERY Society task force consensus statement on protocol standardization. Eur. Heart J. 38, 2805–2812 (2017).

27. 27.

Safavi, K., Mathews, S. C., Bates, D. W., Dorsey, E. R. & Cohen, A. B. Top-funded digital health companies and their impact on high-burden, high-cost conditions. Health Affairs. 38,115–23 (2019).

28. 28.

Hatef, E., Sharfstein, J. M. & Labrique, A. B. Innovation and entrepreneurship: harnessing the public health skill set in a new era of health reforms and investment. J. Public Health Manag. Pract. 24, 99–101 (2018).

29. 29.

Kavanagh, B. P. The GRADE system for rating clinical guidelines. PLoS Med. 6, e1000094 (2009).

30. 30.

American Diabetes Association. 2. Classification and diagnosis of diabetes: standards of medical care in diabetes—2019. Diabetes Care. 42(Supplement 1), S13–S28 (2019).

31. 31.

International Consortium for Health Outcomes Measurement. ICHOM Diabetes Standard Set Released On World Diabetes Day 2018. https://www.ichom.org/news/ichom-diabetes-standard-set-released-on-world-diabetes-day-2018/ (2018).

32. 32.

U.S. Food & Drug Administration. Postmarket Requirements (Devices). https://www.fda.gov/medicaldevices/deviceregulationandguidance/postmarketrequirements/default.htm (2018).

33. 33.

U.S. Food & Drug Administration. Postmarket Surveillance Under Section 522 of the Federal Food, Drug, and Cosmetic Act. https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM268141.pdf (2016).

34. 34.

Plante, T. B. et al. User experience of instant blood pressure: exploring reasons for the popularity of an inaccurate mobile health app. npj Digit. Med. 1, 31 (2018).

35. 35.

World Wide Web Consortium. Notes on User Centered Design Process. http://www.w3.org/WAI/redesign/ucd (2008).

36. 36.

International Organization for Standardization. ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems. https://www.iso.org/standard/52075.html (2010).

37. 37.

UXChallenge. UX Evaluation Criteria. http://uxchallenge.org/user-experience-ux-evaluation-criteria (2018).

38. 38.

Nielsen Norman Group. 10 Usability Heuristics for User Interface Design. https://www.nngroup.com/articles/ten-usability-heuristics/ (1995).

39. 39.

Smelcer, J. B., Miller-Jacobs, H. & Kantrovich, L. Usability of Electronic Medical Records. J. Usability Stud. 4, 70–84 (2009).

40. 40.

Iribarren, S. J., Cato, K., Falzon, L. & Stone, P. W. What is the economic evidence for mHealth? A systematic review of economic evaluations of mHealth solutions. PLoS ONE 12, e0170581 (2017).

41. 41.

Forbes. Credit Scores Vs. Credit Reports: What’s the Difference? https://www.forbes.com/sites/learnvest/2017/02/17/credit-scores-vs-credit-reports-whats-the-difference/#64cc151b35ed (2017).

42. 42.

Kellermann, A. L. & Jones, S. S. What it will take to achieve the as-yet-unfulfilled promises of health information technology. Health Aff. 32, 63–68 (2013).

43. 43.

CNBC. CVS creates new health-care giant as \$69 billion merger with Aetna official closes. https://www.cnbc.com/2018/11/28/cvs-creates-new-health-care-giant-as-69-billion-aetna-merger-closes.html (2018).

44. 44.

USA Today. How Amazon, JPMorgan, Berkshire could transform American health care. https://www.usatoday.com/story/money/2018/02/25/amazon-jpmorgan-berkshire-health-care/350625002/ (2018).

## Acknowledgements

The authors thank Roger Park for his input on the financial industry. This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors.

## Author information

Authors

### Contributions

All authors meet the four criteria detailed in Author Instructions. The author (S.C.M.) was responsible for concept and design, analysis and interpretation of data, creation of figures and tables, drafting and revision of the paper, final approval, and accountability for the work. M.J.M., C.L.H., A.R., A.B.L., and A.B.C. were responsible for elements of design and analysis and interpretation of data, creation of figures and tables, drafting and revision of the paper, final approval, and accountability for the work.

### Corresponding author

Correspondence to Simon C. Mathews.

## Ethics declarations

### Competing interests

The authors declare no competing interests.

Publisher’s note: Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

## Rights and permissions

Reprints and Permissions

Mathews, S.C., McShea, M.J., Hanley, C.L. et al. Digital health: a path to validation. npj Digit. Med. 2, 38 (2019). https://doi.org/10.1038/s41746-019-0111-3

• Accepted:

• Published:

• ### Seeking Meaningful Innovation: Lessons Learned Developing, Evaluating, and Implementing the Electronic Patient-Reported Outcome Tool

• Carolyn Steele Gray

Journal of Medical Internet Research (2020)

• ### The Potential of Clinical Decision Support Systems for Prevention, Diagnosis, and Monitoring of Allergic Diseases

• Stephanie Dramburg
• , María Marchante Fernández
• , Ekaterina Potapova
•  & Paolo Maria Matricardi

Frontiers in Immunology (2020)

• ### Utilizing Digital Health Technologies for Patient Education in Lifestyle Medicine

• Anne Kuwabara
• , Sharlene Su
•  & Jeffrey Krauss

American Journal of Lifestyle Medicine (2020)

• ### Reflections on Digital Health Tools for Respiratory Applications

• Andy Dundon
• , David Cipolla
• , Jolyon Mitchell
•  & Svetlana Lyapustina

Journal of Aerosol Medicine and Pulmonary Drug Delivery (2020)

• ### Systematic Review of mHealth Applications That Interface with Inhaler Sensors in Asthma

• Elaine Nguyen
• , Benjamin Miao
• , Nicholas Pugliese
• , Daniel Huang
•  & Diana M. Sobieraj

The Journal of Allergy and Clinical Immunology: In Practice (2020)


text:
# How do you find the exact value of cos^-1 (-1)?

${\cos}^{- 1} \left(- 1\right)$
$\cos n = - 1$
$n = \frac{3 \pi}{2}$ radians
$n = 270$ degrees


text:
# With OpenGL, is it correct to apply model transformation to rotate the camera?

Having taken a basic CG course, I remember that transformations are relative, so rotating the camera is identical to rotating the view in the opposite direction. Right now I want to implement camera rotation using the mouse. In OpenGL, I can see the family of functions called lookAt() as implemented by the various libraries. However, those take vectors for camera positions. I feel it is incorrect to calculate the vector for camera position when we can rotate the world with a matrix transformation, e.g. using quaternions (as implemented handily by Qt5 or GLM). Thus, is it a correct and adopted solution to apply a transformation to the model matrix as opposed to the view matrix in the following line of code:

gl_Position = proj * view * model * vec4(position, 0.0, 1.0);

ref. https://open.gl/transformations, subsection "Going 3D"?

Or, should I rather apply a rotation transformation as defined by a matrix received using quaternion algebra analogous to the solution above, but, this time around, to the matrix position vector? Will those be identical? (My common sense tells me they will only be identical if the camera is pointing to 0 and the object is located at point 0 - but I lack the required knowledge about transformations yet.)