HP Forum Archive 21

[ Return to Index | Top of Index ]

[WP34S] Speeding up the Romberg Integration Message #1 Posted by Les Wright on 29 May 2012, 5:12 a.m. Just noticed in the SVN that the requirement for 3 diagonal elements of the Romberg matrix to agree to the desired accuracy has been dropped to two. I believe that little is gained in most cases by doubling the running time of a problem (which is indeed what happens since the number of new function evaluations is the same as what one has already done when one moves to a new row), though I know one can argue that some integrands out there will converge spuriously to the wrong value and three element agreement will combat that. But for most problems, I think halving the running time is well worth it. My own port of the original PPC ROM IG routine requires only two elements to agree, and I usually use it in preference to the built in integrator. On my wish list is the ability to control desired accuracy not through FIX n or, preferably, SCI n, but through an actual relative accuracy entered as one does on the 42S. This would enable one to aim for greater accuracy if desired than the ALL 00 or SCI 11 settings allow. Just wanted to commend you on this wise refinement. It had crossed my mind once that it may be worth considering, but I never mentioned it. Les Edited: 29 May 2012, 5:13 a.m.

Re: [WP34S] Speeding up the Romberg Integration Message #2 Posted by Paul Dale on 29 May 2012, 5:31 a.m., in response to message #1 by Les Wright People reading the SVN commit logs. How strange :-) I'd like to improve the integration command eventually. An adaptive Gauss-Kronrod based quadrature or some such. - Pauli

Re: [WP34S] Speeding up the Romberg Integration Message #3 Posted by fhub on 29 May 2012, 5:42 a.m., in response to message #2 by Paul Dale Quote: People reading the SVN commit logs. How strange :-) Not strange at all - I do it every day! ;-) Quote: I'd like to improve the integration command eventually. An adaptive Gauss-Kronrod based quadrature or some such. But please don't remove the Romberg method! If you really switch to any other integration method, then keep also the current method, so the user could decide which one he wants to use. Or at least have Romberg as an external library routine ... Franz

Re: [WP34S] Speeding up the Romberg Integration Message #4 Posted by Dominic Richens on 29 May 2012, 6:42 a.m., in response to message #3 by fhub Quote: Quote: People reading the SVN commit logs. How strange :-) Not strange at all - I do it every day! ;-) Apparently we're a lot stranger than you think!

Re: [WP34S] Speeding up the Romberg Integration Message #5 Posted by fhub on 29 May 2012, 5:50 a.m., in response to message #1 by Les Wright Quote: On my wish list is the ability to control desired accuracy not through FIX n or, preferably, SCI n, but through an actual relative accuracy entered as one does on the 42S. This would enable one to aim for greater accuracy if desired than the ALL 00 or SCI 11 settings allow. Yes, that would be a good idea! But what I won't like is having to enter this desired accuracy each time when calling the integration routine (i.e. as a stack value). I would prefer any user variable (something like deltaX for f' and f''), and if this variable is _not_ defined then it should just use the FIX or SCI setting. Franz

Re: [WP34S] Speeding up the Romberg Integration Message #6 Posted by Paul Dale on 29 May 2012, 6:50 a.m., in response to message #5 by fhub An extra register that specifies the tolerance for x[approx]? tests? perhaps. Not sure if I'll bother but it is worth considering for the future. - Pauli

Re: [WP34S] Speeding up the Romberg Integration Message #7 Posted by fhub on 29 May 2012, 7:10 a.m., in response to message #6 by Paul Dale Quote: An extra register that specifies the tolerance for x[approx]? tests? Well, I didn't really mean a register but rather a label (e.g. 'eps') which could be entered by the user like a program. IIRC there's something similar for the stepsize for f'(x), a label 'dX', unless you've changed this again!? If such a label 'eps' is defined, this value should be used for such routines (solve, integrate, ...), and if not then just the display setting should be used (as it is currently). Franz

Re: [WP34S] Speeding up the Romberg Integration Message #8 Posted by Marcus von Cube, Germany on 29 May 2012, 4:37 p.m., in response to message #7 by fhub Having to write (or delete) a program to set a numeric parameter seems like a bad idea, both for 'eps' and 'dX'. Sadly, we don't have named variables. This leaves either the stack or a named register such as J or K. I see much room for confusion here. The stack is probably the preferred method in both cases. or we have two variants of the commands: One taking the parameter form the stack, the other from the display setting or 'dX' label, respectively.

Re: [WP34S] Speeding up the Romberg Integration Message #9 Posted by fhub on 29 May 2012, 4:45 p.m., in response to message #8 by Marcus von Cube, Germany Quote: Having to write (or delete) a program to set a numeric parameter seems like a bad idea, both for 'eps' and 'dX'. Well, doesn't just such a 'dX' label already exist since a very long time? So it's not _my_ bad idea, I just tried to use the same method as _you_ have already implemented it! ;-) Franz

Re: [WP34S] Speeding up the Romberg Integration Message #10 Posted by Paul Dale on 29 May 2012, 5:40 p.m., in response to message #9 by fhub Just because we've used dX doesn't mean we like it :-( It is an aberration, an exception, ... - Pauli

Re: [WP34S] Speeding up the Romberg Integration Message #11 Posted by fhub on 29 May 2012, 6:09 p.m., in response to message #10 by Paul Dale Quote: Just because we've used dX doesn't mean we like it :-( Why don't you change it then? ;-) What about the following idea: You could make this dX a command (like '# n') with a parameter n (i.e. 'dX n'), and executing this command sets an internal variable to 10^-n (something like setting a 'mode'). And the same could be made for 'eps n' ... Franz Edited: 29 May 2012, 6:10 p.m.

Re: [WP34S] Speeding up the Romberg Integration Message #12 Posted by Paul Dale on 29 May 2012, 6:27 p.m., in response to message #11 by fhub Assuming dX is always of the form 10^-n probably isn't a great idea. So we'd need a backing register and there aren't any available. I'd rather not reuse I, J or K for this. Putting this value on the stack is a possibility but that would get annoying. - Pauli

Re: [WP34S] Speeding up the Romberg Integration Message #13 Posted by fhub on 29 May 2012, 6:40 p.m., in response to message #12 by Paul Dale Quote: Assuming dX is always of the form 10^-n probably isn't a great idea. So we'd need a backing register and there aren't any available. But there's enough place for 'country' and 'calendar' settings??? ;-) Quote: I'd rather not reuse I, J or K for this. I agree. Quote: Putting this value on the stack is a possibility but that would get annoying. Again I agree. And using a label (as it's done now) is also not a good idea. So which option remains? :-(

Re: [WP34S] Speeding up the Romberg Integration Message #14 Posted by Paul Dale on 29 May 2012, 7:46 p.m., in response to message #13 by fhub You're misunderstanding the space these settings require. Country -- zero bits -- we don't store this. The locale setting is exactly the same as running a series of commands setting the modes flags individually. Calendar settings -- 1 bit for the JG switch over date and two bits for the date format. Unfortunately, I don't see how to put a derivative step threshold into three bits. I welcome suggestions but doubt I'll receive anything useful. If you want to be pedantic, there are another few mode bits we could rescue but not enough to create even one register. - Pauli

Re: [WP34S] Speeding up the Romberg Integration Message #15 Posted by Marcus von Cube, Germany on 31 May 2012, 3:39 p.m., in response to message #14 by Paul Dale We can make good use of the present implementation by programming: LBL 'dX' RCL J RTN The 'eps' implementation would then be analogous. So it's up to the user were to store the configuration values. Edited: 31 May 2012, 3:40 p.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall