+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not quite HP Calculators - but related (/forum-8.html)
+--- Thread: DM 42 (/thread-8366.html)
RE: DM 42 - Thomas Okken - 05-25-2017 06:21 PM
(05-25-2017 05:15 PM)toml_12953 Wrote:(05-25-2017 11:11 AM)Paul Dale Wrote: Converting to reals and using real functions is a cheats way out. You'll get the correct answer in this case but it is only hiding the underlying problem.
But when the imaginary part is 0 doesn't that mean the number *is* a real?
It seems more intelligent to treat it that way than to mindlessly use complex routines that aren't necessary.
Tom L
If the case im(z) = 0 is the *only* case that is handled incorrectly, sure. But if the function misbehaves for |im(z)| < ε, only fixing the im(z) = 0 case introduces a discontinuity.
RE: DM 42 - pier4r - 05-25-2017 08:03 PM
Side question: is free 42 a simulator of the hp 42s, bugs/limits included, or is it very close but actually tends to be an independent development based on the 42s?
RE: DM 42 - matthiaspaul - 05-25-2017 09:09 PM
(05-24-2017 11:37 AM)48GX Wrote: DM42Based on this photo I think the key labels could be quite a bit larger (in particular for the digit keys) and the yellow labels could be brighter for easier readability...
Greetings,
Matthias
RE: DM 42 - Thomas Okken - 05-25-2017 10:57 PM
(05-25-2017 08:03 PM)pier4r Wrote: Side question: is free 42 a simulator of the hp 42s, bugs/limits included, or is it very close but actually tends to be an independent development based on the 42s?
Free42 simulates the HP-42S at the user level, so it has different bugs and limits than the original. Compare this to Emu42, which runs original HP ROM images on simulated hardware, which results in it having the same bugs and limits as the original.
From my web site:
Quote:Free42 is a re-implementation of the HP-42S Scientific Programmable Calculator and HP-82240 Printer.
It is a complete rewrite, not using any HP code. It does not require an HP-42S ROM image.
RE: DM 42 - Paul Dale - 05-26-2017 12:05 AM
(05-25-2017 05:15 PM)toml_12953 Wrote: But when the imaginary part is 0 doesn't that mean the number *is* a real?
It seems more intelligent to treat it that way than to mindlessly use complex routines that aren't necessary.
A world of pitfalls lies here. Consider the difference between arcsin(3) and arcsin(3 + 0i). The former should produce a domain error, the latter a result.
A calculator should do exactly what is asked of it, not something that is mostly equivalent.
When there truly is no difference between the two then yes, the real version can be used.
Pauli
RE: DM 42 - matthiaspaul - 05-26-2017 12:18 AM
(05-24-2017 11:37 AM)48GX Wrote: DM42Since the calculator's keyboard area is slightly recessed, it appears to be quite well suited for keyboard overlays in general. Does the case also feature small notches in the rails to the left and right of the keyboard to better afix overlays (like on the HP 48)? If not, that might be a useful tweak to further improve usability.
Greetings,
Matthias
RE: DM 42 - toml_12953 - 05-26-2017 01:37 AM
(05-26-2017 12:05 AM)Paul Dale Wrote:(05-25-2017 05:15 PM)toml_12953 Wrote: But when the imaginary part is 0 doesn't that mean the number *is* a real?
It seems more intelligent to treat it that way than to mindlessly use complex routines that aren't necessary.
A world of pitfalls lies here. Consider the difference between arcsin(3) and arcsin(3 + 0i). The former should produce a domain error, the latter a result.
A calculator should do exactly what is asked of it, not something that is mostly equivalent.
When there truly is no difference between the two then yes, the real version can be used.
The Prime displays 1.57079632679-1.76274717404*i when asked to calculate ASIN(3). It knows enough to use complex when necessary and reals when possible.
Tom L
RE: DM 42 - Paul Dale - 05-26-2017 03:51 AM
How to cut a piece of timber of length 1.57079632679-1.76274717404*i ?
Raising an error can be more useful than mindlessly using complex routines.
RE: DM 42 - Ángel Martin - 05-26-2017 05:33 AM
(05-26-2017 03:51 AM)Paul Dale Wrote: How to cut a piece of timber of length 1.57079632679-1.76274717404*i ?
Raising an error can be more useful than mindlessly using complex routines.
Again, couldn't agree more.
The way the prime makes those assumptions is not a good approach to follow.
The domain matters!
RE: DM 42 - Thomas Okken - 05-26-2017 07:24 AM
(05-26-2017 05:33 AM)Ángel Martin Wrote:(05-26-2017 03:51 AM)Paul Dale Wrote: How to cut a piece of timber of length 1.57079632679-1.76274717404*i ?
Raising an error can be more useful than mindlessly using complex routines.
Again, couldn't agree more.
The way the prime makes those assumptions is not a good approach to follow.
The domain matters!
Isn't this a bit of a pointless discussion? The HP-42S has CPXRES and REALRES modes for precisely this reason. In REALRES mode, SQRT(-1) and ACOS(3) return Invalid Data, while in CPXRES mode, they return i and 0+1.76274717404i. And in either mode, they'll return complex results when given complex arguments, i.e. SQRT(-1+0i) and ACOS(3+0i). Does anyone actually think that there is anything wrong with that kind of behavior?
RE: DM 42 - toml_12953 - 05-26-2017 07:33 AM
(05-26-2017 03:51 AM)Paul Dale Wrote: How to cut a piece of timber of length 1.57079632679-1.76274717404*i ?
Raising an error can be more useful than mindlessly using complex routines.
I'm a theoretical mathematician. What do I know about the real world? If I were to try to cut a piece of timber then try counting on my fingers, I'd have to count in binary!
Tom L
RE: DM 42 - Paul Dale - 05-26-2017 07:34 AM
I'm fine with the 42S's behaviour. CPXRES and REALRES are required.
The question was more: should a calculator switch between real and complex mode automatically? It shouldn't unless told to. This works both ways: (0 + i)2 should give (-1, 0) not -1.
RE: DM 42 - toml_12953 - 05-26-2017 07:41 AM
(05-26-2017 07:24 AM)Thomas Okken Wrote:(05-26-2017 05:33 AM)Ángel Martin Wrote: Again, couldn't agree more.
The way the prime makes those assumptions is not a good approach to follow.
The domain matters!
Isn't this a bit of a pointless discussion? The HP-42S has CPXRES and REALRES modes for precisely this reason. In REALRES mode, SQRT(-1) and ACOS(3) return Invalid Data, while in CPXRES mode, they return i and 0+1.76274717404i. And in either mode, they'll return complex results when given complex arguments, i.e. SQRT(-1+0i) and ACOS(3+0i). Does anyone actually think that there is anything wrong with that kind of behavior?
No, nothing at all wrong with that. Prime can turn that ability on or off. It has a checkbox that allows or disallows complex results from real input also. In my work I need answers whether real or complex. If I was an civil or mechanical engineer or surveyor, I'd probably want an error message rather than a complex result. An electrical engineer likes complex results.
Tom L
RE: DM 42 - AlexFekken - 05-26-2017 10:24 AM
Personally, I don't care too much about rounding issues (accepting to live with rounding was pretty much the first thing I was taught at uni) or picking the "wrong" branch of a multi-valued function (this probably matters more for school or uni exercises than for real-world problems; after all, the "right" branch is pure convention).
Much more interested in when I can buy my DM42 :-)
RE: DM 42 - matthiaspaul - 05-26-2017 11:38 AM
(05-24-2017 04:25 PM)Ángel Martin Wrote: Got my unit and not only looks gorgeous but the keys feel just about right pressure and tactile feeling. If you want this baby to last for, say 10 years, then you don't want it any softer than it is.Hm, properly designed keys shouldn't become softer with age and use...
I haven't had a chance to try the DMxx keys myself yet, but there have been quite many reports indicating that they are somewhat stiffer than on HPs. If so, I'd be in the camp of people preferring them to be a bit softer as well...
Quote:If I were to be picky on the cosmetics I'd like a bolder font, this one is rather small for my eyes.It looks very nice on the photo and I wouldn't have said this ten years ago, but with aging eyes I hope there will be a display mode using a significantly larger font (using up almost the whole display area to display the four stack levels). (About the smallest font size still acceptable for my taste is as on the HP 48, but I don't mind a larger font. The default size on the 50g is already too small to be used comfortably.)
Greetings,
Matthias
RE: DM 42 - Ángel Martin - 05-26-2017 12:19 PM
(05-26-2017 10:24 AM)AlexFekken Wrote: Personally, I don't care too much about rounding issues (accepting to live with rounding was pretty much the first thing I was taught at uni) or picking the "wrong" branch of a multi-valued function (this probably matters more for school or uni exercises than for real-world problems; after all, the "right" branch is pure convention).
Most people are used to and can cope with small differences due to rounding, but the cumulative rounding errors can amount to a totally wrong answer when added up in several intermediate steps.
Regardless, that's not comparable to the complex branch case. Choosing the wrong branch of a multi-valued function is a conceptual mistake that unavoidably leads to a completely wrong result.
RE: DM 42 - toml_12953 - 05-26-2017 12:52 PM
(05-26-2017 07:34 AM)Paul Dale Wrote: I'm fine with the 42S's behaviour. CPXRES and REALRES are required.Maybe for you it shouldn't but for me, it should always give an answer in either the real or complex plane as appropriate. If I could pick only one method, I'd have the calculator always give a numeric answer whether real or complex. If I was working a real-world problem and saw a complex result, I'd know there was no real solution. If the calculator always reported an error when given real inputs, there would be no way of knowing what the actual answer was.
The question was more: should a calculator switch between real and complex mode automatically? It shouldn't unless told to. This works both ways: (0 + i)2 should give (-1, 0) not -1.
Tom L
RE: DM 42 - jch - 05-26-2017 01:17 PM
Just got mine today at 13:00,
SN: 00050 and with a nice gift, a spare "SwissMicros MP42" glass.
About Keyboard stiffness, yes, somewhat stiffer than the original ones but I don't mind, except, maybe, the "ENTER" key wich requires a strong press.
The silkscreen for the shifted keys seems a bit faded out for the three upper rows, though it's still readable, even for my aging eyes.
The display is really impressive, high resolution and very good readability.
I had to use a paper clip to reset my DM42 after I tried to create a 100 x 100 matrix.
That yields to a 'Malloc Error' and I had to reset the calculator. I first tried a gentle pressure, but it requires a firm one.
That seemed to stress the battery, the voltage dropped from 3.04 V to 3.01 V but it is recovering right now (3.03 V).
It is my first SwissMicro device and despite some teething defaults (it's a Beta release after all), I'm very happy with this calc.
Many thanks to Michael, SwissMicro and Thomas!
C'est une chouette calculatrice ! (SCNR)
RE: DM 42 - Ángel Martin - 05-26-2017 01:36 PM
(05-24-2017 01:53 PM)Guenter Schink Wrote: 4. In Alpha-Mode haven't found a way to put in numbers
I have the same issue: can't figure out how to enter numbers in ALPHA...
On the real 42 is simply pressing the number key, so here I had assumed the SHIFT key would be needed since the direct letters are assigned to the keys - but that does *not* work.
Is this a bug?
RE: DM 42 - Thomas Okken - 05-26-2017 04:30 PM
(05-26-2017 01:36 PM)Ángel Martin Wrote:(05-24-2017 01:53 PM)Guenter Schink Wrote: 4. In Alpha-Mode haven't found a way to put in numbers
I have the same issue: can't figure out how to enter numbers in ALPHA...
On the real 42 is simply pressing the number key, so here I had assumed the SHIFT key would be needed since the direct letters are assigned to the keys - but that does *not* work.
Is this a bug?
It's an unfortunate side effect of their decision to add HP-41-style "alpha keyboard" behavior to a UI that was designed very differently. We already beat this topic to death in one of the earlier DM42 threads; the problems were foreseen, and I'm surprised they weren't addressed before the beta release.