[Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement

09202015, 12:58 AM
(This post was last modified: 01142016 12:19 AM by matthiaspaul.)
Post: #1




[Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
Hi,
I'd like to propose a number of easy to implement functional and navigational enhancements for the Prime: The trigonometric functions SIN/ASIN, COS/ACOS and TAN/ATAN are not listed in the menu (Toolbox>Math>Trigonometry lists only COT/ACOT, SEC/ASEC and CSC/ACSC). Apparently, this is because they are directly available via the keyboard and therefore less likely to be selected through the menu. But having some functions available through method A and other functions of the same type available through method B is breaking a basic UI design rule. Consistency is important. (I am aware of the fact, that these functions are available in the soft menu "Toolbox>Catalog", but still.) To the extent possible, users should have the free choice how to select a function (even if some methods are more convenient to use than others most of the time, this may not hold true in all situations or for all users). Therefore, I suggest to add entries for the missing functions to the Math menu as well. If omitting them in the menu is meant to be a feature, a configuration setting should be added to make the desired behaviour ("suppress menu entries for functions available directly via keyboard") userselectable. Going through the list of available hyperbolic functions, I found the following functions missing: COTH/ACOTH, SECH/ASECH, CSCH/ACSCH. They should be provided not only for symmetry reasons. There is another group of trigonometric functions unsupported in the Prime. They are rarely used today, but since it would be comparably easy to add support for them, it would be great if the Prime knew about them by default as well for completeness: versed sine aka versine aka versus aka sagitta: VER (or VSN, SIV) (versed cosine aka) vercosine: VCS coversed sine aka coversine: CVS coversed cosine aka covercosine: CVC haversed sine aka haversine aka semiversus: HAV (or HVS, SEM) haversed cosine aka havercosine: HVC hacoversed sine aka hacoversine: HCV hacoversed cosine aka hacovercosine: HCC See also: http://en.wikipedia.org/wiki/Versine chord: CRD See also: http://en.wikipedia.org/wiki/Chord_(geometry) exsecant: EXS excosecant: EXC See also: http://en.wikipedia.org/wiki/Exsecant (Of them, versine, coversine, haversine and exsecant are the most important ones.) All these functions have inverse functions as well: AVER (or AVSN, ASIV), AVCS, ACVS, ACVC, AHAV (or AHVS, ASEM), AHVC, AHCV, AHCC, ACRD, AEXS, AEXC At present, the Prime supports only degrees (full circle = 360°) and radians (full circle = 2pi). As I have stated elsewhere already (see: http://www.hpmuseum.org/forum/thread449...l#pid40343, http://www.hpmuseum.org/forum/thread542...l#pid48945), I would like to see support added at least for gradians/gons (full circle = 400g < this should be a superscript "g") and turns (full circle = 1) as well. Some suggestions how to further enhance the menu navigation in general: Since selecting functions through menu trees like the Toolbox>Math/CAS/App menus might be inconvenient when a function is needed often, the last selection of each submenu should be stored internally and displayed in a different background color (or in another way to make it visually stand out) in the menu. It should be invocable directly by special hotkey "0" (which is unused in this scenario even in menus with more than 9 entries, as the numbering starts with "1" and continues with "A" after "9" (at least up to letter "O")). Thereby, the last selected entry in a menu could be reinvoked by a sequence of "blind" keypresses of "0"  much faster than going through the menu the normal way. There is (at least up to now) still a free soft menu entry (between "App" and "Catalog"). This could be occupied for "Last" and work identical to "0" as well (for a more logical grouping, "Catalog" could be moved leftwards to make room for "Last" between "Catalog" and "OK"). Invoking functions by other means (not through the menu) should not update the "lastselected entry" of the corresponding submenu, so, if the Toolbox>Math>Trigonometry menu was last used to invoke SEC, invoking f.e. SIN via the function key should not change the menu's lastselectionstate to SIN, but remain at SEC (assuming SIN would be listed in the same submenu as SEC, see above). Further, for quicker navigation inside a menu, the hotkey "." (which is also unused) should jump back and forth between the absolute first and absolute last entry in the current menu list without activating that entry. That is, the first press of "." should jump to entry "1" without activating it, except for when the currently selected entry is already "1", when "." should jump to the absolute last entry in the list instead (similar to a combination of "Shift"+"up" or "down"). Similarly, hotkey "_" (also unused) should jump back and forth between the first and last entries in the currently visible part of the menu list (similar to a combination of pageup/pagedown functions on "Alpha"+"up" and "Alpha"+"down"). The difference between "." and "_" is only visible if the list of menu entries is longer than a screenful and can be scrolled up and down (as f.e. in Toolbox>Math>List). In the menu, "Enter" already works like "right". In addition to this, "Backspace" should work like "left", "+" like "down", "" like "up", "*" like "page down" and "/" like "page up" (useful for longer menus like Toolbox>Math>List), so that key sequences to reach specific menu entries can be memorized more easily and typed in faster than having to switch between the numpad and the cursor pad. Within a menu, it is possible to jump to the next entry starting with letter x by pressing "Alpha" followed by the letter x. If there is no matching entry down the list, the search will continue at the beginning. Most menu entries start with uppercase letters, but there are also a few lowercase entries (like under Toolbox>CAS>Rewrite>Trig). In either case, the search is caseinsensitive and at present "Alpha" and "Alpha" "Alpha" produce the same results. Therefore, "Alpha" "Alpha" could be used to reverse the jumpcycle direction through the menu, that is, it would caseinsensitively select the next matching entry upwards, and if none is found, continue at the end of the list. Since "EEX" is also unused inside of menu lists, it could be used as a "mastershortcut" to directly select the last entry in the last selected submenu even while the focus is still in one of the upper or in "parallel" menus. Let's assume, the last selected function in the Math menu would have been COSH, the user could invoke it by opening the Math menu and press "0" twice. Alternatively, he could open "Toolbox>Math" and just type "EEX" to reinvoke COSH again as well  obviously, this gets more convenient the deeper a function is buried in the menu tree. With a menu like "Toolbox>Math" open, pressing direct function keys of the "x^y" to "log" and "x^2" to "," rows should automatically close the menu and directly invoke the pressed function. It shouldn't be necessary to press "Esc" first. However, if a menu with more than 9 entries is active, letters are used to invoke a menu entry directly, so this suggestion could either work only for menus with less than 10 entries in general, or the menu selection function should override the standard function of the key at least for those letters occupied by the corresponding menu. Greetings, Matthias See also: http://www.hpmuseum.org/forum/thread542...l#pid49015  "Programs are poems for computers." 

09202015, 05:55 PM
(This post was last modified: 09202015 06:08 PM by primer.)
Post: #2




RE: [Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
Hi Mattias,
(09202015 12:58 AM)matthiaspaul Wrote: There is (at least up to now) still a free soft menu entry (between "App" and "Catalog"). This could be occupied for "Last"... If I understand correctly, you speak about toolbox menu, if so, I'm sorry but there are no more free soft menu here. Between "App" and "Cat", there is the "User" menu (the one that lists user programs). however, I liked that idea. Regards. 

09202015, 09:20 PM
(This post was last modified: 09212015 12:35 AM by matthiaspaul.)
Post: #3




[Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
(09202015 05:55 PM)primer Wrote:Yes.(09202015 12:58 AM)matthiaspaul Wrote: There is (at least up to now) still a free soft menu entry (between "App" and "Catalog"). This could be occupied for "Last"...If I understand correctly, you speak about toolbox menu, Quote:if so, I'm sorry but there are no more free soft menu here.Thanks for your valuable feedback. The "User" menu didn't show here so far, that's why I assumed it would still be unoccupied realestate in the softmenu. Quote:however, I liked that idea.Fortunately, the fact that "Last" cannot be added to the softmenu doesn't break the general idea. Let's see: While Shift + "OK" might work nicely semantically as well, it wouldn't save keystrokes (compared to "0" or "EEX") or improve on the usability idea that all functions of the device should be reachable through any input method without being forced to combine different methods (some may be more convenient than others, but they may not be available all the time or may be difficult to memorize or perform by some users or in some usage scenarios). Alternatively, pressing the already selected soft menu entry (like "Math", "CAS" or "App") again is already occupied with closing the menu again, so this won't work well either. But if we slightly change the proposed behaviour, clicking on the menu's title bar could serve as something between the proposed functions for "0" and "EEX": Pressing the (blue) title bar of the menu (like "Math") while the menu's submenus are still closed, would open all submenus at once according to what was invoked the last time (similar to a sequence of "0"), but not execute it immediately (as "EEX" would do). At present, clicking on the title bar with the submenus closed does nothing, so no documentation would have to be changed. Further, if the user would click on the menu's title bar with some or all of the submenus opened, it would close all the submenus but keep the main menu open (just as it does right now already). Greetings, Matthias  "Programs are poems for computers." 

09212015, 08:28 PM
Post: #4




Missing trigonometric/hyperbolic functions, possible navigational enhancement
Versed sine aka versine: VSIN (or VERS)
versed cosine aka vercosine: VCOS (or VERC) coversed sine aka coversine: CVSIN (or CVS) coversed cosine aka covercosine: CVCOS (or CVC or CVCS) haversed sine aka haversine aka semiversus: HVSIN (or HAV, HVS, SEM) haversed cosine aka havercosine: HVCOS (or HVCS, HVC) hacoversed sine aka hacoversine: HCVSIN (or HCVS) hacoversed cosine aka hacovercosine : HCVCOS (or HCVC, HCVCS) chord: CRD exsecant: EXSEC (or XSEC) excosecant: EXCSC (or XCSC) Interesting & apparently archaic. Are there common modern uses for these functions? 

09222015, 02:09 PM
(This post was last modified: 09222015 08:23 PM by matthiaspaul.)
Post: #5




[Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
(09212015 08:28 PM)Dwight Sturrock Wrote: Interesting & apparently archaic. Are there common modern uses for these functions?Since they can be substituted by variations on sine, cosine etc., I guess most people today use them implicitly without telling them by their names or even not recognizing them in their own right. In some cases they can be used to improve accuracy (like LNP1 and EXPM/EXPM1) by avoiding catastrophic cancellation or to simplify calculations, but I see them mostly as sometimes convenient macros today. They have various uses in spherical trigonometry in fields like navigation, meteorology, geodesy and astronomy. I have seen them being used in optical formulas for photographic lenses, in applications for apodization and beamforming, in filter design, signal processing and analysis, in the design of control systems, as well as in statistics. The vonHann function comes to my mind. I seem to remember it also from discussions of the theory behind wireless radio standards. To have a complete set of trigonometric functions may also be beneficial for educational purposes, f.e. in discussions of the unit circle. And finally, don't missing out on any functions (or even expanding into previously uncovered areas) may also be considered as a "sign of excellence" in comparisons with competitor products. Greetings, Matthias  "Programs are poems for computers." 

09222015, 02:21 PM
Post: #6




RE: [Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement  
09222015, 03:22 PM
(This post was last modified: 09222015 03:23 PM by matthiaspaul.)
Post: #7




[Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
(09222015 02:21 PM)DrD Wrote: "Wireless radio?"Yes, the term "radio" might be misleading here, I can't help the tautology. ;) "Wireless radio" is a commonly used, but more abstract term in the industry for the modem / transceiver part in devices like mobiles / cellphones / smartphones, but not limited to them. Greetings, Matthias  "Programs are poems for computers." 

09222015, 06:02 PM
(This post was last modified: 09222015 08:57 PM by matthiaspaul.)
Post: #8




[Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
(09202015 09:20 PM)matthiaspaul Wrote: But if we slightly change the proposed behaviour, clicking on the menu's title bar could serve as something between the proposed functions for "0" and "EEX":Thinking about it, this proposed toggle behaviour when ticking on a menu's title bars could also be handy when using the keyboard only  in addition to the proposed "0" and "EEX" hotkeys: "EEX" is useful if you quickly need to invoke the previously selected function (f.e. by pressing "Toolbox" followed by "EEX"), and "0" is convenient for quicker navigation in "recently" used areas of the menu. Ticking on the menu's title bar selects like "EEX", but in order to execute you will still need to tick on the selected entry (or press "Enter"). This gives the user the option to easily override the previous selection with another nearby function  it often happens that similar functions are needed in sequence. For example, in a formula containing a SINH you might also need COSH, which can be found nearby SINH in the menu (you get the idea). Further up, I suggested to let "Backspace" work like "Left" inside an open menu. "Left" and "On" subsequently close the corresponding submenu(s) and the main menu. Anyway, the "Backspace" behaviour should deviate from it by closing submenus, but not closing the main menu. Instead it should "open last submenu" like when ticking on the menu title bar. The resulting behaviour of "Backspace" would be to first close any open submenus one after the other on subsequent keypresses, then open the "last submenu" again, and then restart to close the submenus again, and so on. So, with SINH being used previously, one could just blindly press "Toolbox" "Backspace" to open the menu with hyperbolic functions, where COSH can be found and selected quickly. Also, just like a sequence of "0" would allow to quickly navigate down the menu tree to the (or a) previously selected entry, "Backspace" would allow to navigate upwards the hierarchy of the previously selected entry, with semantically similar functions very likely to be on nearby menu entries and therefore much quicker to reach than going through the menu the normal way. Also, this cycling behaviour of "Backspace" would be completely in analogy with the proposed cycling behaviour of "Backspace" in an input line, as suggested here: http://www.hpmuseum.org/forum/thread4667.html Greetings, Matthias (Edit: During testing I thought to have found that "Left" would not close the main menu, whereas "On" does, but I cannot reproduce this now a day later, when both keys will also close the main menu. Apparently, I had temporarily activated "Alpha".)  "Programs are poems for computers." 

10312015, 08:25 PM
Post: #9




RE: [Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
I am not sure if it would count as a trig function as it would also have uses elsewhere: But seeing as haversines and astronomy have been mentioned...
I would like to see a function I have never noticed (perhaps it is in a calculator somewhere). REDUCE_RANGE. in astronomical algorithms one frequently calculates some angle and then wishes to take its sin... But first, the spec glibly says "reduce range" (eg from 362 degrees to 2 degrees, or 25 h to 1 h). If there could be a reduce range function, that would be great as I could just call it and carry on. Of course, one can simply use a modulo function... But by the time I have thought about the range required (0..360? 180..180?) And written a test program to check how MOD on that compiler handles negatives (some languages may produce different results), I will have forgotten the application code I was in the middle of. Or to carry on with the application coding, you could ignore getting bogged down in MOD syntax, and repeatedly subtract... No chance of bugs there, until you use a very large angle . A reduce_range function makes it immediately clear what your code is trying to ach hiieve with minimum distraction and close similarity to the spec. Stephen Lewkowicz (G1CMZ) 

10312015, 08:37 PM
(This post was last modified: 10312015 08:37 PM by Han.)
Post: #10




RE: [Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
If you are going to eventually take the sine (or cosine, or any trig. function) of the value, then
\[ \sin(362^\circ) = \sin(2^\circ) \] so why should it matter? I must not be understanding your post correctly... Graph 3D  QPI  SolveSys 

11012015, 11:18 AM
Post: #11




RE: [Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
(10312015 08:37 PM)Han Wrote: If you are going to eventually take the sine (or cosine, or any trig. function) of the value, then Han, it is far more likely that it is me not explaining it well. If it is indeed a case of sin 362=sin 2 that I was trying to remember, all I can suggest is perhaps some sin algorithms lose precision or calculate for a longer time when given sin 1e30, rather than reducing the range first. Either that, or they are reusing an algorithm designed for looking up numbers from log tables Whatever the reason and details, several astronomical algorithms do specify a range reduction  Unfortunately, most of my astronomical code is locked away inside an Amiga 1200 computer for which I no longer have a power supply, so I can't refresh my memory right now. Stephen Lewkowicz (G1CMZ) 

11042015, 06:38 PM
(This post was last modified: 11122015 12:56 PM by matthiaspaul.)
Post: #12




RE: [Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
(09212015 08:28 PM)Dwight Sturrock Wrote:The doublepage 4243 in the July/August 2015 issue (#227) of the "Ocean Navigator" journal has an article about a very recent (2014) usage example for haversines for longhand sight reduction by Hanno Ix and Greg Rudzinski:(09202015 12:58 AM)matthiaspaul Wrote: [...]Interesting & apparently archaic. Are there common modern uses for these functions? http://issuu.com/navigatorpublishing/doc...ad_edition http://fer3.com/arc/imgx/AllHaversinDoniol.pdf It is based on an older method proposed by R. Doniol in the 1950s1970s, but refined to only use haversines. Greetings, Matthias  "Programs are poems for computers." 

11052015, 06:49 AM
Post: #13




RE: [Prime] Missing trigonometric/hyperbolic functions, possible navigational enhancement
Hello,
>But first, the spec glibly says "reduce range" >(eg from 362 degrees to 2 degrees, or 25 h to 1 h). >If there could be a reduce range function, that would >be great as I could just call it and carry on. Range reducing is performed automatically by the trig functions before calculating the sin/cos/tan. In order to preserve accuracy as much as possible the reduction is performed on 31 significant digits (as opposed to the normal 15). And is done in such a was as to be as fast as possible (basically, a fast modulo). The reduction is done, not on 360°, but on 45° as the trig function only calculates for angles in the 0 to 45° range. Once the angle is reduced to 45°, it is finally converted to radians and the real trig function is executed. Doing a prereduce of the input would not lead to speed up or accuracy improvement, but to the reverse as temporary objects would need to be created and the intermediate result would have lost some of its precision (because user numbers have only 12 digits). The only time where you would see a gain is if you were to do a lot of calculations based on the same very large number... However, if you have an angle in the 1e30 range, well, you do NOT have an angle as you only have a number with precision in the 1e18 range (3012) while your angle is in the 1e2 range, so you have in reality no idea what angle you are working with and your calculation does not make sense... Cyrille Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)