WP43 News

This area is for discussion about these families of custom high-end Scientific Calculator applications for SwissMicros devices.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S News

Post by Walter »

Well, let a hundred flowers bloom,... (百花齐放,...) 8-)

(Two remarks: Referring to the fathers in their wisdom, please look at the HP-45; I admit this was not programmable though.
Inserting a submenu, you lose 1/18 of the menu - using [up] or [down] instead, you lose nothing. )
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S News

Post by Jaymos »

Walter wrote:
Sun Apr 25, 2021 11:01 am

Inserting a submenu, you lose 1/18 of the menu - using [up] or [down] instead, you lose nothing.

I know that well. Pros and cons. I just wanted to mention that there is value in your short fixed menus, maybe needed for these bridge functions. As a menu it can find its way to a User key too.

But for me it’s 50/50, I’m just recognising the difference.
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
User avatar
pauli
Posts: 252
Joined: Tue May 02, 2017 10:11 am
Location: Australia

Re: 43S News

Post by pauli »

There are spaces in both the EXP and TRI menus, so we're not losing anything. Unless we start adding sec, cosec, cot and their hyperbolic equivalents :twisted:

Jacobi's sn an cn are related to sin/sinh and cos/cosh respectively, so they might be a problem adding to the TRI menu (like sinh/cosh). There isn't space in the EXP menu.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S News

Post by Walter »

How about the second view of TRI ? Just a suggestion though...

(And don't forget appearing with new function proposals whenever we're approaching complete implementation of the function set specified. Remember the various ways to kill a project. ... Feature creep ...)
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
User avatar
RAPo
Posts: 290
Joined: Wed May 03, 2017 6:54 pm
Location: The Netherlands
Contact:

Re: 43S News

Post by RAPo »

Indeed as indicated below is a solution that works for me.
tuxfish wrote:
Sun Apr 25, 2021 2:37 am
Option #2 plus the extension posted by @pauli concerning "add a new menu for elliptic functions.", if possible, please.
Thanks! You are doing great stuff ! :thumbs up:
DM41X beta: SN00018.
DM41X: SN00496.
DM42 beta: SN00074.
DM42:SN06020.
DM42 converted to C47 SN08973
DM10L: SN056/100.
DM11L: SN 02058.
DM15L: SN2074.
DM16L: SN2156.
DM15, DM16, DM41
and a whole bunch of the original HP's,
User avatar
ManuMa
Posts: 24
Joined: Sun Mar 15, 2020 10:14 pm
Contact:

Re: 43S News

Post by ManuMa »

I much prefer option #1. I use much more y^x than EXP menu.
Also, sqrt is more useful unshifted, as x^2 is easily done by Enter *
Maybe 30 years of HP41 usage has something to do with this. I was shocked when I used an HP Prime for the first time, as it has x^2 as an unshifted function. Then I realized that as it is not a true RPN calculator, operations easily done using the stack were placed unshifted, clearly indicating its algebraic soul.

Regards,
Manuel.
gmac42
Posts: 103
Joined: Fri Jun 01, 2018 11:30 am

Re: 43S News

Post by gmac42 »

tl;dr:
I'm for option 2 with Pauli's suggestion.

To elaborate a bit:
My first impulse was option #1, because I tend to use y^x more often then most of the EXP menu.
But otoh, this would make everything in EXP three keypresses away, instead of two. And, as you pointed out, as long as the menu is opened, y^x is accessible with one keystroke. Also, having EXP and TRI next to each other looks nice and consistent to me, but that's probably just a matter of taste.
I feel it's weird to have y^x shifted on the same key that opens the EXP menu, which also gives access to this function. So, that place would lend itself to adding another menu.
DM41X #542, DM42 #650, DM41L #801, HP 41CX, HP 41CV, HP 50G, HP11C, TI 89
gmac42
Posts: 103
Joined: Fri Jun 01, 2018 11:30 am

Re: 43S News

Post by gmac42 »

PS: And if I'll find out that I really use y^x so often that I want it directly on an unshifted key, there's always the User Mode.
DM41X #542, DM42 #650, DM41L #801, HP 41CX, HP 41CV, HP 50G, HP11C, TI 89
gjmcclure
Posts: 4
Joined: Thu Apr 22, 2021 8:04 pm

Re: 43S News

Post by gjmcclure »

Walter wrote:
Mon Apr 19, 2021 9:50 pm
Tataaa! We succeeded in building our first release. Please find it here: https://gitlab.com/Over_score/wp43s/-/releases :D

Therein is everything you may want to try, test, and check our 43S. The new stuff encompasses almost complete statistic functions, curve fits incl. regression plots (thanks to Jaco!). Please look into the manuals to find more news. Enjoy! :D

And if you discover anything weird, please react differently to prior times: please report.
Got the build. Noticed I needed GTK3 Runtime, so installed that.
I run wp43s.exe and get "The procedure entry point InflateReset2 could not be located in the dynamic link library C:\...\Win64\bin\libpng16-16.dll.
It is follow by anther similar message for deflateSetHeader. I run on Windows 10 64-bit. I installed GKT3 for Win64. Did I misunderstand the intructions for installing? Greg.
User avatar
GeisiX
Posts: 14
Joined: Thu Mar 18, 2021 11:47 pm
Location: Bavaria

Re: 43S News

Post by GeisiX »

Following gmac42's train of thought, I feel obliged to revise my earlier rather impulsive vote for Option #1.

As pointed out, although I feel that I, personally, use y^x more than any of the other EXP-menu operations, the fact that the menu stays open as long as it is not replaced by another one eluded me at the time I casted the vote. Taking this into account and the fact that the global balance of keypresses required has its optimum in Option #2, this seems to be the more reasonable approach.

What we all should not forget is that there won't be the perfect solution for everyone in the community (e. g. me preferring base-10-operations for my frequent use in the field of acoustics while base-e-operations are the predominant operations in natural sciences etc.). Freely following Walter's earlier comments: "Don't let perfect (for a few) be the enemy of good (for many)." And it is not some fundamental stuff like the infamous "+-*/"-key arrangement discussion either.

That said and being happy about the possibility to fiddle around in USER mode, I am looking forward to the next release. Still very impressed with the project and what the team has conjured up to this point.
Post Reply