|
wp34S Spelling Out Function Names?
|
|
|
|
« Next Oldest | Next Newest »
|
▼
Post: #2
06-08-2011, 10:59 AM
 Hi Guys, Frequently when I'm accessing a wp34S function, I can't remember whether it is in the "X.FCN" or "P.FCN" catalogs and have to exit the current catalog and enter the correct one. Was any consideration ever given to additionally allowing the user to spell out the function name, similar to the HP41? Pressing [XEQ] [ENTER] (for ALPHA) and spelling out the name currently searches for labels in program memory, but couldn't it search through the built-in function names first?
Thanks, ▼
Post: #3
06-08-2011, 11:18 AM
Quote:I agree Jake, an excellent idea - or should I better say eXEQellent idea. ;-) Maybe this should work for ALL implemented functions, even for those already on the keyboard like SIN, ACOS, ATANH, etc. ... ▼
Post: #4
06-08-2011, 11:30 AM
Oh yeah. As Pauli wrote: Everything is public. Feel free to design, code, test, and implement it. Enjoy! Walter ▼
Post: #5
06-08-2011, 12:02 PM
Quote:Well, I didn't mean that you should completely reorganize your program structure or your list(s) of functions - it should only be possible to execute any implemented function by directly entering the name instead of navigating through the menus. But I finally get it: any improvement suggestions are not welcome here, and the usual answer to such feature requests is something like your sentence above. So this is my last posting here, I wish you much success in improving your WP34S project.
Cheers, ▼
Post: #6
06-08-2011, 02:27 PM
Hallo Franz, Quote:There are many participants who can tell you that the opposite is true. It's more a matter of timing - you joined pretty late and fired a lot of ideas which would have been appreciated much much more if they would have been sent significantly earlier. Right now we're happy we made it so far. After all it was not only fun, but also a lot of labor. After some rest, we will be more open for new suggestions for sure - but remember it's easier making suggestions than bringing the whole thing up and running. I'd wish you'll continue enjoying this forum. Walter ▼
Post: #7
06-08-2011, 03:22 PM
Quote: If he's the type of person who is so fragile that he would leave the forum just because of one post, maybe it's for the best... Eric
Post: #8
06-08-2011, 04:10 PM
Quote:I hope you're kidding. Read my answer explaining the reasons why this function simply will not fit in the current software. We've done a lot to add features requested in this forum and we're still adding more. Your proposal is especially useful and I had already discussed it with my fellow developers some time ago. The conclusion was that it does not fit easily due to flash space constraints.
Post: #9
06-08-2011, 05:36 PM
I think you've misunderstood. We have a limited amount of time to devote to the project & believe me we've devoted a *lot* already. We're very willing to listen to suggestions and in many cases in the past we have implemented them. We can't do this for everything, there are way too many changes people want. There are some good reasons why implementing commands via their alpha labels isn't going to be a quick and easy task (I can go into this in more detail if people want to be bored by it all). So rather than spend my time implementing a feature which strictly isn't necessary (since every function -- except one -- is already available from the keyboard), I'd prefer to spend my time doing other things like fixing bugs and getting the beta release out.
So where does this leave you as the person making the suggestion? Talk is cheap. Actions aren't.
▼
Post: #10
06-08-2011, 07:01 PM
Pauli, as usual, your remarks are proper and sensitive. If all replies about the 34s were as helpful and thoughtful of the feelings of others as yours, no one would ever complain. As you said, talk is cheap, and unthoughtful replies are often free. ▼
Post: #11
06-08-2011, 07:10 PM
They'd still complain :-) Thanks for the kind voice of support. - Pauli ▼
Post: #12
06-08-2011, 07:24 PM
Page 58 of 81: In the h CAT catalog description, it specifies 0 - 2 as the flash segments. Isn't this 0-3 now? At least, 0-2 on page 58 seems inconsistent with the description on page 12 of 81. I'm thinking I'm either confused (possibly) or that page 58 should say 0-3. :-) Also on page 12 of 81, it references segments 2, 1 and 0 in that order. Should that be 3, 2, 1, and 0? Paragraph on page 12 is below. "Else, i.e. if xy is an alpha label of up to three characters of arbitrary case, searching will start at program step 000 and cover the entire memory in the sequence RAM, flash segment 2, flash 1, flash 0, and XROM, independent of the position of the program pointer."
And, again, for the record, I consider the flash "pages" 1, 2, and 3 and their ability to be called as subroutines or executed in place as perhaps one of the most substantial features of the entire WP 34s! Edited: 8 June 2011, 10:24 p.m. ▼
Post: #13
06-09-2011, 12:40 AM
Gene, Thanks for your observations and for sharing them :-) No, you are not confused :-) the project was just moving a bit faster than the author. Most important: It's corrected and committed now d:-) Walter
Post: #14
06-09-2011, 12:43 AM
Quote: Very interesting. I consider them a bit of extra program memory (okay a pile) that's fractionally safer than normal program memory.
Post: #17
06-08-2011, 04:05 PM
It's not as easy as it sounds. In order to make the search possible we have to sort the commands by name and create a catalogue from them. This is done by an external program during the compile process and included as a table in the resulting object. In theory that is no problem, but in fact it is... We're just running out of possible code space. We would need about 2 KB for the catalogue table alone. Gone are the library regions...
Post: #18
06-08-2011, 11:27 AM
Hi Jake, Probably you've expected the following: yes, also our catalogs have a long history. Especially it took many (!) months until the alpha search function was tackled and implemented for more than one character. Until then scrolling was the dominant browsing method, and we split the ever growing set of extra functions into several separate catalogs for easier practical handling. With a convenient search method as we feature it now, we won't have to do it again to this extent, but now we've done it. But life is quite easy: Commands containing a '?' are in TEST, all mode setting is in MODE, distributions are in PROB, statistics beyond distributions is in STAT. And CONV as well as CONST are self-explanatory. The separation of P.FCN and X.FCN is not as evident and contains some arbitrary decisions for sure - we may merge at least those two and regain one label, but that won't be a big gain and we are a bit tired/lazy now after all. Within X.FCN in particular, you may benefit from fast typing on an alphabetic keyboard (3 s timeout, good luck!). So this comes pretty near to what you want, AFAIK. Walter
▼
Post: #19
06-08-2011, 12:01 PM
Quote: Another situation I find myself facing is when I am entering program steps and go to a catalog, searching for an integer-mode function, but the appropriate catalog does not currently show that function because the machine is currently in DECM mode. As a result, I must exit the catalog, exit program mode, enter integer mode, re-enter program mode and then re-enter the catalog in order to be able to enter the function as a program step. Being able to spell the function under these circumstances would be another big time-saving benefit, for what it is worth. Jake ▼
Post: #20
06-08-2011, 02:34 PM
One solution for this problem is merging the different flavors of X.FCN and adding P.FCN, so you'll get one big catalog for the "standard stuff". It's contents would be independent of the mode (integer, DECM, PRG) you are in. Sounds like this is what you want, don't you? This looks like a "minor change" besides the label P.FCN becoming obsolete. Walter ▼
Post: #21
06-08-2011, 04:20 PM
Jake, you're facing some of the problems I've struggled with when I joined the project. The problem is that we still have the flash space problem which prevents us from adding lengthy catalogues. Before we can add these features, be assured we want to do this, we need to squeeze out the software to a much higher extent than we've already done. It's hard work, no more low hanging fruit, I'm afraid.
Post: #22
06-08-2011, 05:40 PM
This would be a simple enough change. It would also save some flash space (a very small amount but still some). I've hit the integer mode functions problem a couple of times & it is annoying. Still, programs that change between real and integer mode aren't all that common -- you got lucky with the IEEE floating point conversion ones :-)
Post: #23
06-09-2011, 06:00 AM
Quote:
Walter, I myself have encountered this problem in the past, and the merging of the two catalogs would be really welcome to me, especially if it would be independent on the mode. Cristian ▼
Post: #24
06-09-2011, 06:36 AM
We didn't implement a full merge.
We also merged the two MODE catalogues together again. So mixed mode integer/real programming will be less painful.
▼
Post: #25
06-09-2011, 09:47 AM
Quote: This is appreciated. Thanks |
