HP Forums
[WP34S] Speeding up the Romberg Integration - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: [WP34S] Speeding up the Romberg Integration (/thread-223276.html)



[WP34S] Speeding up the Romberg Integration - Les Wright - 05-29-2012

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 - Paul Dale - 05-29-2012

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 - fhub - 05-29-2012

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 - fhub - 05-29-2012

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 - Dominic Richens - 05-29-2012

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 - Paul Dale - 05-29-2012

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 - fhub - 05-29-2012

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 - Marcus von Cube, Germany - 05-29-2012

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 - fhub - 05-29-2012

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 - Paul Dale - 05-29-2012

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 - fhub - 05-29-2012

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 - Paul Dale - 05-29-2012

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 - fhub - 05-29-2012

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 - Paul Dale - 05-29-2012

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 - Marcus von Cube, Germany - 05-31-2012

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.