Future version of DM32 using a complex data type?

Discussion around the SwissMicros DM32 calculator
User avatar
RJvM
Posts: 276
Joined: Wed Jun 02, 2021 9:21 am
Location: Gelderland, Netherlands

Future version of DM32 using a complex data type?

Post by RJvM »

Would anyone else like a future version of the DM32 software, which was reengineered anyway, so not an old version, to support complex datatype, like DM42, WP43 or C47?
Robbert Jan, MSEE, RPN user since 1976 and a collector for many years I now own all the important ones: HP-35, 45, 55, 65, 97, 19, 21, 25, 34, 10-16, 41, 42, 71, 48, 50, Prime, DM41, DM42, WP43, C47, R47; Project 47 team member https://47calc.com
BruceH
Posts: 82
Joined: Sat May 06, 2017 2:39 am

Re: Future version of DM32 using a complex data type?

Post by BruceH »

Not especially.
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Future version of DM32 using a complex data type?

Post by rprosperi »

Though it's too early to speculate on future features, I agree with Bruce. It's simply not possible to seamlessly bolt-on complex operations for a machine that does not do them natively. The result is always awkward and difficult to use, or it would destroy the simplicity of the 32Sii paradigm.

Also, users needing extensive use of complex data will typically also need the kinds of features found in the more advanced machines you mentioned.

For me, the most interesting stories I've read about HP design meetings and spec decision making were about what features to NOT include in a new device. It's easy to enumerate more and more things a device could do, but much harder, and IMHO more important, to limit it to what it should do.

[steps down off the pulpit...]
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
User avatar
RJvM
Posts: 276
Joined: Wed Jun 02, 2021 9:21 am
Location: Gelderland, Netherlands

Re: Future version of DM32 using a complex data type?

Post by RJvM »

I can follow this line of reasoning easily and I accept the approach, keep it clean. Though I would have liked to see the entry sequence reversed, real part first, seems cleaner.
Robbert Jan, MSEE, RPN user since 1976 and a collector for many years I now own all the important ones: HP-35, 45, 55, 65, 97, 19, 21, 25, 34, 10-16, 41, 42, 71, 48, 50, Prime, DM41, DM42, WP43, C47, R47; Project 47 team member https://47calc.com
User avatar
pauli
Posts: 252
Joined: Tue May 02, 2017 10:11 am
Location: Australia

Re: Future version of DM32 using a complex data type?

Post by pauli »

real ENTER complex x<>y meets the alternate workflow.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: Future version of DM32 using a complex data type?

Post by Walter »

pauli wrote:
Wed May 24, 2023 8:30 am
real ENTER complex x<>y meets the alternate workflow.
:lol:

I guess you meant real ENTER imaginary x<>y though. Or real ENTER imaginary x<>y COMPLEX ? Who knows? ;)
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
J-F Garnier
Posts: 47
Joined: Sun Mar 11, 2018 5:37 pm
Location: France

Re: Future version of DM32 using a complex data type?

Post by J-F Garnier »

RJvM wrote:
Tue May 23, 2023 5:52 pm
Would anyone else like a future version of the DM32 software, which was reengineered anyway, so not an old version, to support complex datatype, like DM42, WP43 or C47?
I wouldn't, no.
I like to way the 32SII manages complex numbers for simple calculations.
Moreover, due to the chosen display format (32SII-like), the 42S way is not possible.
And now on the DM32, you can see both the real and imag parts at the same time.
rprosperi wrote:
Wed May 24, 2023 12:59 am
Though it's too early to speculate on future features, I agree with Bruce. It's simply not possible to seamlessly bolt-on complex operations for a machine that does not do them natively. The result is always awkward and difficult to use, or it would destroy the simplicity of the 32Sii paradigm.

Also, users needing extensive use of complex data will typically also need the kinds of features found in the more advanced machines you mentioned.
For extensive use, sure the 42S model is better.
But for occasional use, the 32SII model is fine, except it is too limited (due to ROM full, very likely)
I several times ported 42S code with complex numbers to the 32S/32SII,
and I know by experience - not by theory - what simple improvements would be welcome for easier use, in a keep it simple spirit.
Probably I already mentioned my point of view several times in the past, as early as 2001.

J-F
User avatar
pauli
Posts: 252
Joined: Tue May 02, 2017 10:11 am
Location: Australia

Re: Future version of DM32 using a complex data type?

Post by pauli »

Walter wrote:
Wed May 24, 2023 8:39 am
I guess you meant real ENTER imaginary x<>y though. Or real ENTER imaginary x<>y COMPLEX ? Who knows? ;)
Someone who knew how to use the 32sii would know.
redglyph
Posts: 177
Joined: Sat Dec 22, 2018 11:45 am

Re: Future version of DM32 using a complex data type?

Post by redglyph »

rprosperi wrote:
Wed May 24, 2023 12:59 am
For me, the most interesting stories I've read about HP design meetings and spec decision making were about what features to NOT include in a new device. It's easy to enumerate more and more things a device could do, but much harder, and IMHO more important, to limit it to what it should do.
That's a very good point, feature creep often does more harm than good.
Aardwolf
Posts: 11
Joined: Sun May 21, 2023 9:38 am

Re: Future version of DM32 using a complex data type?

Post by Aardwolf »

Imho, if not a complex data type, at least just support the left-out functions the same way as now: it makes no sense that x^y is supported but e.g. x^2 is not.

It would totally not be feature creep to support it for inverse trig, hyperbolics and their inverses, sqrt, x^2, 10^x, log10(x), abs, etc..., if anything it feels more like feature creep to implement an error message for those instead of just returning x^2 if you already have x^y implemented, and have the user guess which ones are supported and which not (like, trig is supported but inverse trig not? why?)
Post Reply