SIMPLIFY command..... another 50g bug?

[pin224466]

the following matrix was entered and stored in a variable called 'MAT'

%%HP: T(3)A(R)F(.);
[[ 'C^2' 'S*C' '-(C^2)' '(-S)*C' ]
[ 'S*C' 'S^2' '-(S*C)' '-(S^2)' ]]
'MAT'
STO

then a value for C was stored..
9
'C'
STO

the matrix was placed on level 1 of the stack then SIMPLIFY was executed (several times).
the result was that substitution occurred only where the simple variable 'C' was located.
%%HP: T(3)A(R)F(.);
[[ 'C^2' '9*S' '-(C^2)' '-(9*S)' ]
[ '9*S' 'S^2' '-(9*S)' '-(S^2)' ]]


note the C^2 variables were not substituted.

now, start over with the original matrix.
multiply the matrix another variable... let use 'B'

MAT
'B'
*

now for the substitution of C.

SIMPLIFY
result is that C is substituted correctly in all locations where variable C existed.

%%HP: T(3)A(R)F(.);
[[ '81*B' '(9*S)*B' '-(81*B)' '-((9*S)*B)' ]
[ '(9*S)*B' '(S^2)*B' '-((9*S)*B)' '-((S^2)*B)' ]]


now a simpler test.
'C^2'
SIMPLIFY
no value substituted.

'C^2*U'
SIMPLIFY
value for C substituted correctly

'C'
SIMPLIFY
no value substituted.

'C*U'
SIMPLIFY
value for C substituted correctly

the easy solution is to use EXPAND. this does not seem to demonstrate the inconsistent execution of SIMPLIFY.


the question is how many other functions utilize the same code as the SIMPLIFY command and could this be preventing solutions from being produced.

[John H Meyers]

Isn't SIMPLIFY an algebraic command, whereas

WHERE (symbol | ) and [up/down]MATCH are commands
more useful for substituting numeric values?

Many algebraic commands (e.g. ISOL, SOLVE[VX], INT[VX], DERIV[VX])
can not be performed
if variables having the name in the expression currently exist.

The HP49/50 series was somewhat "complexified" (as to the
difficulty of implementing a CAS) by the extreme constraints
of memory, ROM and the operating system,
so "give the poor thing a break"
and get Mathematica -- of course I mean the iPhone App:

<http://www.wolfram.com/news/alphaapp.html>
<http://www.wolfram.com/broadcast/video.php?channel=90&video=894>

---Quoting <http://en.wikipedia.org/wiki/Wolfram_Alpha> ---

Wolfram Alpha is written in 15 million lines of Mathematica
(using webMathematica and gridMathematica) code
and runs on 10,000 CPUs (though the number was upgraded for the launch).

The database currently includes hundreds of datasets, such as "All Current and
Historical Weather". The datasets have been accumulated over several years.

As well as its own built in database, Wolfram Alpha also answers queries
based on live data from external sources such as Facebook, CrunchBase,
Best Buy and the FAA. Within two weeks of launching the Facebook
analytics service, 400,000 users had used it.

--- End quote ---

I tried "please find phone numbers
of 50 single compatible girls within 25 miles
who are curvaceous, have no sharp corners,
look and can fly like that lady in Goldfinger,
and preferably have their own airplane"
but the whole thing just locked up on me.

-[ ]-

[pin224466]

On Sunday, February 3, 2013 4:12:36 AM UTC-6, John H Meyers wrote:

> Isn't SIMPLIFY an algebraic command, whereas
> WHERE (symbol | ) and [up/down]MATCH are commands
> more useful for substituting numeric values?

In a program, O.K.; however, when equations are input from the keypad or EQW... simplify & eval seem a more reasonable set of operations/keystrokes to perform.

but then again, potato.. potatoe.... right??

Regardless, the execution of SIMPLIFY is inconsistent and can cause bugs in programs when execution is expected to occur in a known/defined way as shown in the first post.

> Many algebraic commands (e.g. ISOL, SOLVE[VX], INT[VX], DERIV[VX])
> can not be performed
> if variables having the name in the expression currently exist.

Is this because the functions are using underlying code that is not operating consistently/correctly?

> The HP49/50 series was somewhat "complexified" (as to the
> difficulty of implementing a CAS) by the extreme constraints
> of memory, ROM and the operating system,

I've read this point of debate before..... see Tim Wessman's response here:

https://groups.google.com/forum/#!searchin/comp.sys.hp48/bug/comp.sys.hp48/R3Pp62J_9SM/hQMf3NXECaIJ


here's a suggestion... start by eliminating the unnecessary garbage in the ROM such as:

http://www.calc-bank.com/index.php?mod=news&ac=commentaires&id=1678

it appears that at least the CAS developers self-portraits have been removed in v2.15, but the rest of the easter eggs remain.

Add to the ROM elimination list, add the following:
1. streamsmart (for which no hardware implementation for 49/50 series is found
OR if there is one, move this application to a library in port 2)
2. minehunt


And there is indication that generation after generation of different developers may have caused the ROM to be consumed unnecessarily as pointed out here:

https://groups.google.com/forum/#!topic/comp.sys.hp48/6RE8oRiSQ2s


however, the issue with further repairs to the ROM appears be that the existing applications/libraries that everyone has written (most of which are freely available on hpcalc) would have to be partially re-written....

as discussed here (starting with Software49G post dated 10/17/11):

https://groups.google.com/forum/#!searchin/comp.sys.hp48/streamsmart/comp.sys.hp48/Sat2INCwjqg/DUitA7bLJ-0J

Since no user would be required to install the updated ROM, this would seem to be a choice on the existing HP owners part to have a calculator with less bugs or keep the old ROM and have compatibility with existing hpcalc programs (at least until developers update their software)

> so "give the poor thing a break"
> and get Mathematica -- of course I mean the iPhone App:

> Wolfram Alpha is written in 15 million lines of Mathematica
> (using webMathematica and gridMathematica) code
> and runs on 10,000 CPUs (though the number was upgraded for the launch).

if mathematica did not function as the documentation stated it was supposed to, the mathematica user community would ask the same question... when is it going to be fixed?


I have found it interesting that the HP User community established and maintained a site to track/report the problems with this product here:

http://bugs.hpcalc.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=


I've seen the comp.sys.hp48 postings indicating what the HP development teams have gone through from approximately the year 2000 - 2009.

Today, an HP calculator group exists and there is active development on HP calculator products.

One would think there might be at least some level of acknowledgement from the current calculator group that the 50G is a product that is still for sale.

There no longer appears to be any indication from HP that the bugzilla information is important.

It seems that HP may have chosen to abandon support for this product by simply ignoring it.


I have not spent a significant amount of time reviewing the current list of active bugs on the hpcalc bugzilla. It appears some of the bugs in that list have been resolved and the list has simply not been updated to acknowledge the fix.

Several other discovered bugs do not appear to have ever been added to the list.

The only recent addition to the list appears to have been made by user HAN and covers the bug discussed here:

http://bugs.hpcalc.org/show_bug.cgi?id=255

(unfortunately, I cannot find Han's posting to comp.sys.hp48 discussing/identifying this bug)


Maybe this is an indication the user community is giving up on the 49/50G and (as J. Meyer's suggested) is transitioning to mathematica (the desktop version instead of paying $$'s for data transmitted via an Iphone)...


Here's a summary of 49/50g bugs that do not appear to be input to the hpcalc bugzilla bug list (the one's that I have been able to find documented):

1. IFTE graphing bug (with a workaround but not a fix):

https://groups.google.com/forum/#!searchin/comp.sys.hp48/bug/comp.sys.hp48/R3Pp62J_9SM/hQMf3NXECaIJ


2. SOLVE/ISOL bug when variables are in alphabetical order or flag -114 set different:
https://groups.google.com/forum/?fromgroups#!topic/comp.sys.hp48/paE6nVB4yd8

which, upon further research, was actually found back in 2009 under ROM 2.09 here:

http://h30499.www3.hp.com/t5/Calculators/ISOL-Behavior/m-p/1090927#M4956

and may actually have been indicated in this post here:

https://groups.google.com/forum/?fromgroups#!searchin/comp.sys.hp48/single$20result$20from$20list/comp.sys.hp48/uXmcBspn1-o/dA4wSSDnXuYJ

3. The SIMPLIFY bug when ENG or SCI 1 or 2 is selected:

https://groups.google.com/forum/?fromgroups#!topic/comp.sys.hp48/Wi_TP3v-AGk


4. The 'lim' function bug where 'lim' shows an 'inconsistent order' error inconsistently when evaluating a simple function:

http://h30499.www3.hp.com/t5/Calculators/Unable-to-solve-extremely-simple-limit/m-p/5708471#M11539

5. The 'dB' bug that causes a calculator hang-up but not crash:
https://groups.google.com/forum/#!topic/comp.sys.hp48/cfecKlmM6wI


6. The '-0/-0' = 1 evaluation bug discussed here:

https://groups.google.com/forum/#!topic/comp.sys.hp48/4X9odi7lWbk

7. the TAG function bug discussed here (although indicated to be related to an already reported bug):

https://groups.google.com/forum/#!searchin/comp.sys.hp48/bug/comp.sys.hp48/Q4mCCBN2sa0/hXMwor7qi5gJ

8. the String length limits bug:

https://groups.google.com/forum/#!topic/comp.sys.hp48/3xwfYZmNJ9U

9. the INFORM function not type-check/validate 'type 28', etc input correctly bug:

https://groups.google.com/forum/?fromgroups#!searchin/comp.sys.hp48/real$20array/comp.sys.hp48/J2ct9YvoGxE/QdBCxlL3g34J

10. the RE() and IM() functions bug:

https://groups.google.com/forum/?fromgroups#!searchin/comp.sys.hp48/array/comp.sys.hp48/479EomyiPeM/sdvT6UVhl8wJ

11. The inconsistent application of a 'PI/180' multiple when using DERVX and INTVX with trig functions when in Degrees mode.

https://groups.google.com/forum/#!topic/comp.sys.hp48/OxW83Gp_RbQ

12. the information contained in this comp.sys.hp48 post's first entry.

How many others have been discovered but not posted because the 49/50 user community no longer sees HP doing anything about it?

[Travis Evans]

On Fri, 15 Feb 2013 14:17:33 -0800 (PST), pin224466 <pin2...@yahoo.com> wrote:
>
>> The HP49/50 series was somewhat "complexified" (as to the
>> difficulty of implementing a CAS) by the extreme constraints
>> of memory, ROM and the operating system,
>
> I've read this point of debate before..... see Tim Wessman's response here:
>
> https://groups.google.com/forum/#!searchin/comp.sys.hp48/bug/comp.sys.hp48/R3Pp62J_9SM/hQMf3NXECaIJ
>
>
> here's a suggestion... start by eliminating the unnecessary garbage in the ROM such as:
>
> http://www.calc-bank.com/index.php?mod=news&ac=commentaires&id=1678
>
> it appears that at least the CAS developers self-portraits have been removed in v2.15, but the rest of the easter eggs remain.
>
> Add to the ROM elimination list, add the following:
> 1. streamsmart (for which no hardware implementation for 49/50 series is found
> OR if there is one, move this application to a library in port 2)
> 2. minehunt

[...]

I've heard of these issues too and have been wordering if there is some
reason that some of the functionality in the ROM couldn't be split out
to external, optionally-installable libraries to make more room? Is it
so integrated into the system that it must remain in the ROM? Is it a
question of software compatibility?

I know HP has wanted to stay away from significantly redesigning the
system due to the immense development cost in doing so; however, it's
looking to me like the 48/49/50 series has advanced so far and aged to
the point that limitations like these are becoming a serious problem.
If it's going to survive much longer, *something* will have to be done
sooner or later...

--
Travis

[John H Meyers]

On 2/15/2013 4:17 PM, pin224466 wrote:

> here's a suggestion... start by eliminating the unnecessary garbage in the ROM such as:
>
> http://www.calc-bank.com/index.php?mod=news&ac=commentaires&id=1678
>
> it appears that at least the CAS developers self-portraits have been removed in v2.15, but the rest of the easter eggs remain.
>
> Add to the ROM elimination list, add the following:
> 1. streamsmart (for which no hardware implementation for 49/50 series is found

ISTR that the "developer portraits" were in the same, originally "locked" "boot block"
that was required for self-tests, rom upload (to other calcs)
and other code now required for ARM-based calcs -- not actually part of the
"Saturn" cpu's ROM code, and that the "stream" code itself actually replaces
that very same location, outside of "Saturn ROM" (except for a very small "stub"
for the UserRPL command which launches it).

In my body there seems to be something called an "Appendix"
which is likewise without function, but you can hardly manufacture
a living human without one, it seems, and whatever God rules over HP
could be just as stubborn about changing anything further in the 50G,
but if things be otherwise, the lips of anyone who actually knows
are sealed by NDAs, which is sort of like having a "time machine"
that lets you go to the future, but there's no
"reverse gear" that lets you come back and use the info today :)

-[ ]-