Future 40/50g Firmware Thoughts/Suggestions
- From: schlie <schlie@xxxxxxxxxxx>
- Date: Sun, 15 Mar 2009 20:16:23 -0700 (PDT)
Being encouraged that someone(s) now appears to be officially working
on improving the 50g's firmware, judging from the newly posted 2.14
ROM on HPCalc.org (which is great news, thank you); I just wanted to
post a few thoughts on potential improvements to it's interface
behavior, hopefully helpful to all users, especially new ones
(feedback/criticism welcome):
- It would be nice if it weren't necessary to set/switch calc modes to
specific settings just to get the results one would normally expect
(as modes such as exact/approx, real/complex, etc. should be merely
treated as being the preferred form of calculation/results, but not
absolutely required to perform a specified calculation). Thereby more
specifically:
exact/real: preserve exact portion of result, otherwise prefer real.
exact/comp: preserve exact portion of result, otherwise prefer comp.
approx/real: exact only if whole result is exact, otherwise prefer
real.
approx/comp: exact only if whole result is exact, otherwise prefer
comp.
prefer real: complex results are converted to reals if having a zero
imaginary component.
prefer comp: complex results are preserved regardless of its imag
comp.
- Correspondingly, all functions should automatically convert any
value specified into it's most closely equivalent form as may be
required by a function (be it real, complex, angular vs. radians) if
compatible, and correspondingly return a result consistent with the
specified mode preference setting as described above; and never
require modes be changed.
For example, currently y^x and x/root/y will needlessly yield an error
if y is a complex and x is a rational fraction, unless converted
manually to a real if not in approx mode; rather than it being simply
converted automatically as may be required, and thereby avoiding
confusion.
- Along a similar vein, it would be awful nice if plotting were
extended to enable both real and imaginary components of a function to
be graphed simultaneously with hypothetically the imaginary part (or
arbitrary second function) being drawn as a dotted line along with the
real part of the primarily specified function being drawn with a solid
line.
- With respect to display font selection, there seem to be a few
quirks remaining, which would be nice to see fixed/refined. For
example:
Explicitly based values such as #3Bh and symbols with Stack:Small
selected will use a smaller font, but normal values will not for some
reason.
Textbook equations on the stack use a small font if
EQW:Small_Stack_Disp is selected, but also shrinks normal value font
as well.
It appears that Stack:Small and EqW:Small_Stack_Disp flags have been
mixed up, where the font selected for normal values has been
incorrectly tied to EqW:Small_Stack_Disp, not Stack:Small flags?
Ideally, it seems simpler to specify whether whether one wants to
select a smaller font to be used for values otherwise either 2x taller
than the selected system font, and/or otherwise wider than the
display's width.
- Further, it would be very nice to see another option for equation
display format, possibly called "Symbolic", where like "TextBook", it
pretty prints equations; but rather than cluttering up the display
with tall fractions and roots, it instead favors the compact display
of exponentials. For example:
x^(a/b)/y^(c/d) =>
a/b -c/d
x * y
not:
a
-
b
x
---
c
-
d
y
or other similarly horrid textbook formatted equation with roots when
rational exponentials are specified.
- As a possibly minor nit, in exact mode it seems inconsistent that
'x' x^2 => sq(x), while 'x' 2 y^x => x^2 as expected for both; thereby
would be nice to see the former also yield x^2 for consistency.
- CAS state/variables should not corrupt local variables (I suspect
they should be stored in their own dedicated CAS_VAR subdirectory; as
possibly should also be the case for various equation libs).
- if a variable has been defined within the current context, it seem
that it's value is substituted regardless of the Numeric flag settings
within CAS; although I may misunderstand, and may not be related.
- The standard display mode should allow a thousands separator to be
specified; along with the maximum digits of displayed precision. (so
large numbers are easier to read, while simultaneously limiting the
maximum width of displayed values without having to otherwise specify
a fixed format which will always display a fixed number of digits for
all real values).
Overall, it seem that if mode and variable dependencies that the
various capabilities depend upon were cleaned up to establish any
modes/values required within their own local environment, converting
any values as may be require themselves, returning only values/
variables expected and useful to the then current user environment;
combined with a few tweaks to the display mode semantics and ideally
graphing capabilities; the user experience (particularly for new
users) would be substantially improved. Thereby inevitably improving
HP's acceptance by new users, as being the preferred tool by all those
requiring more than the most basic of capabilities, without having to
otherwise conquer the idiosyncrasies of
the machine.
.
- Follow-Ups:
- Re: Future 40/50g Firmware Thoughts/Suggestions
- From: sc_usenet
- Re: Future 40/50g Firmware Thoughts/Suggestions
- From: Veli-Pekka Nousiainen
- Re: Future 40/50g Firmware Thoughts/Suggestions
- From: schlie
- Re: Future 40/50g Firmware Thoughts/Suggestions
- Prev by Date: Re: TopSecret program [49 series]
- Next by Date: Re: New ROM 2.14
- Previous by thread: New ROM 2.14
- Next by thread: Re: Future 40/50g Firmware Thoughts/Suggestions
- Index(es):
Relevant Pages
|
Loading