Both WP 31S and WP 34S manuals now available for individual POD

[Bit]

(02-22-2015 01:44 PM)walter b Wrote:  

(02-22-2015 10:33 AM)Marcus von Cube Wrote:  Local registers don't increase the amount of available memory they just make a different use of it.

Know that, been there. Nevertheless, assume a function 'Σa' looking like this for a stack depth of 8 levels:

Code:

LBL 'Σa'
LocR 9
STOS .1
Σ 'S'
STO .0
RCLS .0
RTN

So 'Σa' would do the same as Σ and save the stack. The only problem to be solved is the transfer of the address of the routine containing the function to be summed up (here 'S'). See what I mean? And if 'Σa' would call itself again recursively, everything will be fine until we run out of memory - just the way it should work.

d:-)

This should be best done right in the functions that destroy the stack. In case you're interested, I have an unpublished and unfinished patch that starts like this:

Code:

// Control if higher order functions (solve, integrate, sum, product, f', f'')
// save the stack:
//      0 or undefined: stack isn't saved
//      1:              stack is saved only if called directly from keyboard
//      2:              stack is always saved (may use a lot of memory)
#define HIGHER_ORDER_FUNCTIONS_SAVE_STACK 1

I've only implemented it for f', f'', Σ and Π so far, solve and integrate are still missing. I haven't yet tested it a lot, but the procedure of adding such a feature is relatively straightforward. Because of possible nesting, as Marcus pointed out, option 2 would probably not be very useful.

[walter b]

Well, as you wrote:

Quote:stack is always saved (may use a lot of memory)

(emphasis added).

Those who use nested functions of this kind should know what they are doing. And they can control it by setting stack size as they need it. OTOH, destroying seven stack levels just for nothing doesn't look like a reasonable alternative IMHO.

Of course, YMMV.

d:-)

[Bit]

(02-22-2015 04:45 PM)walter b Wrote:  Well, as you wrote:

Quote:stack is always saved (may use a lot of memory)

(emphasis added).

Those who use nested functions of this kind should know what they are doing. And they can control it by setting stack size as they need it. OTOH, destroying seven stack levels just for nothing doesn't look like a reasonable alternative IMHO.

Even saving a 4-level stack could use a lot of memory in nested calls and that would make the 34S less capable. Perhaps a secondary set of opcodes, that don't save the stack, could be provided as a fourth option.

[walter b]

(02-22-2015 05:05 PM)Bit Wrote:  

(02-22-2015 04:45 PM)walter b Wrote:  Those who use nested functions of this kind should know what they are doing. And they can control it by setting stack size as they need it. OTOH, destroying seven stack levels just for nothing doesn't look like a reasonable alternative IMHO.

Even saving a 4-level stack could use a lot of memory in nested calls and that would make the 34S less capable.

Not true IMHO. Nobody forces you to use nested calls. If you do, however, you must pay the price. If you don't want to, don't use these functions.

d:-)

[Bit]

(02-22-2015 05:49 PM)walter b Wrote:  Not true IMHO. Nobody forces you to use nested calls. If you do, however, you must pay the price. If you don't want to, don't use these functions.

Pauli and Marcus are in a better position to comment on the impact of increased memory requirements. In any case, I'm happy to contribute my patch, or even improve it later, if that's the direction the 34S goes.

[MarkHaysHarris777]

hi Walter,

I'm really liking your book, genuinely; again, thanks, its very well done and very helpful--- has what is needed right up front for newbies, and just enough fluff and historical references to make it interesting and fun. I would recommend it to anyone who loves the WP34s (as I do!) and wants a good reference work (paper is good, colors are good, and the ref content is fabulous).

I plan to order a copy for each of my college students as well.

Thanks again!

Cheers,
marcus

[walter b]

Thanks, Mark, for your very kind words.

d:-)

[Paul Dale]

(02-22-2015 04:23 PM)Bit Wrote:  I haven't yet tested it a lot, but the procedure of adding such a feature is relatively straightforward.

Make sure you test with both 4 and 8 level stacks....
This part of the xrom code is hard wired to four levels and doesn't know if there are eight or not


- Pauli

[Bit]

(02-23-2015 10:08 PM)Paul Dale Wrote:  Make sure you test with both 4 and 8 level stacks....
This part of the xrom code is hard wired to four levels and doesn't know if there are eight or not

I took care of that. However, I've just realized that while the current patch saves and restores the correct number of registers, it's a bit wasteful since it allocates 8 extra registers even if only 4 are needed. If this is a feature you'd like to include in the 34S, I can create a better patch relatively soon, otherwise it's a low priority item for me.

[walter b]

(02-24-2015 03:23 AM)Bit Wrote:  If this is a feature you'd like to include in the 34S, I'll can create a better patch relatively soon, otherwise it's a low priority item for me.

I'd very much welcome if

• f'(x) and f"(x) would take the location and return the derivative in X, working as monadic functions;
• Σ and Π would take the counter and return the sum/product, working as monadic functions as well;
• SLV would take two initial estimates of the root in X and Y and return xroot in X, the second last x-value tested in Y, and f(xroot) in Z, working as a function of type (-1) as described in the manual.
• ∫ would take the lower and upper integration limits in Y and X, respectively, and return the (approximated) integral in X and an upper limit of its uncertainty in Y, preserving the rest of the stack.
  

Then I'd vote for including these improvements in the standard FW of the WP 34S.

d:-)

[Bit]

(02-24-2015 05:39 AM)walter b Wrote:  I'd very much welcome if

• f'(x) and f"(x) would take the location and return the derivative in X, working as monadic functions;
• Σ and Π would take the counter and return the sum/product, working as monadic functions as well;
• SLV would take two initial estimates of the root in X and Y and return xroot in X, the second last x-value tested in Y, and f(xroot) in Z, working as a function of type (-1) as described in the manual.
• ∫ would take the lower and upper integration limits in Y and X, respectively, and return the (approximated) integral in X and an upper limit of its uncertainty in Y, preserving the rest of the stack.
  

Then I'd vote for including these improvements in the standard FW of the WP 34S.

There's one aspect of this I'm unsure about: proper error handling without xIN/xOUT. Any comments on that?

[Paul Dale]

(02-24-2015 05:39 AM)walter b Wrote:  [*]∫ would take the lower and upper integration limits in Y and X, respectively, and return the (approximated) integral in X and an upper limit of its uncertainty in Y, preserving the rest of the stack.

You had better go back and read the manual from an ancient HP featuring this function. This is not how integrate handles the stack. Try the HP-34C manual page 211, the 15C is the same.

You input limits in X and Y, it returns the integral in X, the uncertainty in Y, the upper limit in Z and the lower limit in T.


- Pauli

[Paul Dale]

(02-24-2015 06:00 AM)Bit Wrote:  There's one aspect of this I'm unsure about: proper error handling without xIN/xOUT. Any comments on that?

You have to do something manually. Error handling was very painful when I wrote these.

xIN/xOUT routines can't call back to user code, so we can't use them.
Code in XROM that doesn't use these, forces a four level stack so the stack manipulations for solve and integrate will be problematic -- although a new command or two would fix this. Push-stack-up that depends on the user's setting not the current system's idea. Or an XROM only LocR that allocates registers and saves the stack, or even a single command that does both -- i.e. save the stack and allocate registers and push the stack up 1 or 2 levels.

I don't think there is an easy solution to Walter's desires -- if there was I'd have done it I suspect.


If we're willing to accept a cleared stack instead, making CLSTK use the user's setting and then doing the stack fix up later would be a fair bit easier. At least for everything except solve and integrate.


- Pauli

[Gerald H]

(02-24-2015 07:53 AM)Paul Dale Wrote:  

(02-24-2015 06:00 AM)Bit Wrote:  There's one aspect of this I'm unsure about: proper error handling without xIN/xOUT. Any comments on that?

You have to do something manually. Error handling was very painful when I wrote these.

xIN/xOUT routines can't call back to user code, so we can't use them.
Code in XROM that doesn't use these, forces a four level stack so the stack manipulations for solve and integrate will be problematic -- although a new command or two would fix this. Push-stack-up that depends on the user's setting not the current system's idea. Or an XROM only LocR that allocates registers and saves the stack, or even a single command that does both -- i.e. save the stack and allocate registers and push the stack up 1 or 2 levels.

I don't think there is an easy solution to Walter's desires -- if there was I'd have done it I suspect.


If we're willing to accept a cleared stack instead, making CLSTK use the user's setting and then doing the stack fix up later would be a fair bit easier. At least for everything except solve and integrate.


- Pauli

Very interesting, but probably demands a new thread.

Meanwhile createspace resolutely continues to ignore my complaints of their fraudulent activity in sending me a book I didn't order rather than the one referenced in the link at the beginning of this thread.

[rprosperi]

(02-24-2015 09:55 AM)Gerald H Wrote:  

(02-24-2015 07:53 AM)Paul Dale Wrote:  You have to do something manually. Error handling was very painful when I wrote these.

xIN/xOUT routines can't call back to user code, so we can't use them.
Code in XROM that doesn't use these, forces a four level stack so the stack manipulations for solve and integrate will be problematic -- although a new command or two would fix this. Push-stack-up that depends on the user's setting not the current system's idea. Or an XROM only LocR that allocates registers and saves the stack, or even a single command that does both -- i.e. save the stack and allocate registers and push the stack up 1 or 2 levels.

I don't think there is an easy solution to Walter's desires -- if there was I'd have done it I suspect.


If we're willing to accept a cleared stack instead, making CLSTK use the user's setting and then doing the stack fix up later would be a fair bit easier. At least for everything except solve and integrate.


- Pauli

Very interesting, but probably demands a new thread.

Meanwhile createspace resolutely continues to ignore my complaints of their fraudulent activity in sending me a book I didn't order rather than the one referenced in the link at the beginning of this thread.

Gerald - If you send me (PM or email) the details of your order (account name/number, order #, date, etc.), I would be happy to try to call Createspace to see if they will resolve the issue. Long Distance from Vienna may cost more than the book!

[Gerald H]

Thank you for your offer of help, Bob. Just sent you a PM with the details.

[Gerald H]

Hooray, an answer from createspace.

Using the link at the start of this thread they claim I ordered Manual for 3.2.

Could you, walter, perhaps contact createspace & advise them that your link makes no mention of version 3.2 throughout the ordering process?

I wonder why I could have wanted 3.2 when the WP 34S I have are 3.3? Seems strange to me.

[Didier Lachieze]

(02-24-2015 04:08 PM)Gerald H Wrote:  Using the link at the start of this thread they claim I ordered Manual for 3.2.

In your order confirmation from CreateSpace you should have a Title ID number.
The Title ID for 3.2 is : 4106229 (order page is https://www.createspace.com/4106229)
The Title ID for 3.3 is : 5304580 (order page is https://www.createspace.com/5304580)

In the picture below you can see a sample order with the two versions of the manual: different Title ID and different price.
   

[Gerald H]

(02-24-2015 04:22 PM)Didier Lachieze Wrote:  

(02-24-2015 04:08 PM)Gerald H Wrote:  Using the link at the start of this thread they claim I ordered Manual for 3.2.

In your order confirmation from CreateSpace you should have a Title ID number.
The Title ID for 3.2 is : 4106229 (order page is https://www.createspace.com/4106229)
The Title ID for 3.3 is : 5304580 (order page is https://www.createspace.com/5304580)

In the picture below you can see a sample order with the two versions of the manual: different Title ID and different price.

Dear Didier,

Thank you for your interest.

Below is the text of my order confirmation:

Hello Gerald Hillier,

Thank you for your recent order.

This email is confirmation of your purchase - please be sure to save it for your records.

IMPORTANT NOTE: Your credit card statement will show CREATESPACE as the merchant name for this order.

Order Confirmation Number: 62563643
____________________________________________________________
Qty Description Format Price Ext. Price
------------------------------------------------------------------------
1 WP 34S Owner's Manual Book $34.00 $34.00
------------------------------------------------------------------------

Order Total:
Subtotal: $34.00
Shipping: $7.99
Tax Collected: $0.00
-------
Total: $41.99

Paid by: Credit Card
______________________________________________________

This shipment will be sent via Expedited Shipping to:
Gerald Hillier
Premreinerg 35/3/2
Vienna A-1130
Austria

Have a question? Visit https://www.CreateSpace.com/OrderHelp

Thank you for shopping with CreateSpace!
----

Note: this e-mail was sent from a notification-only address that cannot accept incoming e-mail.


I reiterate: I ordered 3.3.

[Gerald H]

(02-24-2015 04:22 PM)Didier Lachieze Wrote:  

(02-24-2015 04:08 PM)Gerald H Wrote:  Using the link at the start of this thread they claim I ordered Manual for 3.2.

In your order confirmation from CreateSpace you should have a Title ID number.
The Title ID for 3.2 is : 4106229 (order page is https://www.createspace.com/4106229)
The Title ID for 3.3 is : 5304580 (order page is https://www.createspace.com/5304580)

In the picture below you can see a sample order with the two versions of the manual: different Title ID and different price.

By the way, Didier, I just walked through the ordering process again & there was no mention of alternative versions to order, it was only mentioned in the page addressed by walter's link, & there it only says 3.3.