[WP34S] Speeding up the Romberg Integration



#2

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.


#3

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


#4

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


#5

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!

#6

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


#7

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


#8

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


#9

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.


#10

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


#11

Just because we've used dX doesn't mean we like it :-(
It is an aberration, an exception, ...

- Pauli


#12

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.


#13

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


#14

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? :-(


#15

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


#16

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Integration question and "RPN" mode comment Craig Thomas 16 1,460 12-05-2013, 02:32 AM
Last Post: Nick_S
  WP34s integration trapped in infinite loop Bernd Grubert 25 1,644 10-17-2013, 08:50 AM
Last Post: Dieter
  HP Prime integration Richard Berler 1 300 10-06-2013, 10:52 PM
Last Post: Helge Gabert
  integration on 39gII emulator Wes Loewer 29 2,014 06-07-2013, 05:58 PM
Last Post: Chris Smith
  WP-34S Integration Richard Berler 15 1,096 03-08-2013, 02:29 AM
Last Post: Walter B
  HP 34S integration Richard Berler 16 1,038 02-18-2013, 04:42 PM
Last Post: Marcus von Cube, Germany
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 322 10-04-2012, 04:59 PM
Last Post: Paul Dale
  New variant for the Romberg Integration Method Namir 8 648 04-18-2012, 07:47 AM
Last Post: Nick_S
  Romberg Integration for 33s, 35s Matt Agajanian 9 636 03-26-2012, 10:00 AM
Last Post: Nick_S
  HP 32sII Integration Error of Standard Normal Curve Anthony (USA) 4 427 03-14-2012, 03:18 AM
Last Post: Nick_S

Forum Jump: