Future version of DM32 using a complex data type?
Future version of DM32 using a complex data type?
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
Re: Future version of DM32 using a complex data type?
Not especially.
Re: Future version of DM32 using a complex data type?
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...]
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
DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Re: Future version of DM32 using a complex data type?
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
Re: Future version of DM32 using a complex data type?
real ENTER complex x<>y meets the alternate workflow.
Re: Future version of DM32 using a complex data type?
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
-
- Posts: 47
- Joined: Sun Mar 11, 2018 5:37 pm
- Location: France
Re: Future version of DM32 using a complex data type?
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.
For extensive use, sure the 42S model is better.rprosperi wrote: ↑Wed May 24, 2023 12:59 amThough 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.
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
Re: Future version of DM32 using a complex data type?
That's a very good point, feature creep often does more harm than good.rprosperi wrote: ↑Wed May 24, 2023 12:59 amFor 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.
Re: Future version of DM32 using a complex data type?
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?)
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?)