▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 228
Threads: 7
Joined: Aug 2011
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!
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Just because we've used dX doesn't mean we like it :-(
It is an aberration, an exception, ...
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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? :-(
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
|
