HP Prime: Error reports : Here



#98

Please, feel free to report errors, typos and so on in this topic.
I will feedback to beta tester forum, Tim will also do.

Please note that the labels have been heavily reviewed in English, French and Chinese.

So many of the errors you find in theses languages may be already corrected.

User Guide (UG) in English have been heavily reviewed/corrected too.


#99

So does x^y work backwards in RPN mode or is it mislabeled? I'd think it calculates y^x, but maybe it's my dyslexia...


mislabelled


Not mislabeled, there is no x/y/z stack and has not been since RPL.

Power works identically and on the 50 - as does nthroot.


used my 41CX :) since it is RPN

Edited: 16 July 2013, 2:17 p.m.

I realize I'm beating a dead horse but... if there's not x/y/z... why does the key label have one "x" and a "y"? Sure you have to call those registers something, but choosing the backwards convention is a bit too REVERSED notation for me :-)

Welcome to R-RPN !

Edit: The 48 and even the 50 have the good'old "Y^X" legend, why change it?

Edited: 16 July 2013, 2:09 p.m.


>Edit: The 48 and even the 50 have the good'old "Y^X" legend, why change it?

Because the 38g didn't.

Quote:
...does x^y work backwards in RPN mode or is it mislabeled? I'd think it calculates y^x...

Exactly so. There was some discussion of this key notation at HHC 2012. It took me some time to realize that the key was simply an arbitrary exponentiation operator. There's no implication of the order of entry for base and exponent to be read from the key's label. That's because there are no X and Y registers.

The HP 39gII follows the same convention. On the non-RPN HP 39gII, the X^Y key notation seems to imply (to me) that that the exponent (Y) is entered first, followed by the X^Y key, followed by the base(X). But it isn't. The base is entered first, followed by X^Y key, followed by the exponent.

Similarly, for the Prime in RPN mode, the base is entered first, followed by the exponent, followed by the X^Y key. There's been no return to the old HP-35 X^Y convention of 41 years ago.


Quote:
the key was simply an arbitrary exponentiation operator. There's no implication of the order of entry for base and exponent to be read from the key's label.

But there is an implication: it's labeled following the algebraic rule which is "linear, direct order", thus first the base (x) and then the exponent (y).

Unfortunately the RPN mode has to live with this contradicting convention, and therefore the glitch. We (RPN users) are second class citizens in this and it shows!

It has nothing to do with RPL, as proven by the "Y^X" legend on all the RPL models. For that matter, even the 35s has "Y^X" despite being dual RNP/Algebraic so I guess the Prime is dual "Algebraic/RPN", the order matters.

Not the biggest deal in the world considering the beast, but still a shame.

PS. Had I been a beta tester I would have insisted from the first moment - i guess that's why they didn't choose me :-)

Edited: 17 July 2013, 2:20 a.m.


You are implying order where none exists. x is a variable, y is a variable. They are arbitrary variables.

a^b b^a q^p are all equivalent from that viewpoint.

Should have just made the button be ^ and then we wouldn't have had this joyous anthill turned into a mountain again. :-)


Quote:
Should have just made the button be ^ and then we wouldn't have had this joyous anthill turned into a mountain again. :-)

Quite so.

At HHC 2012, when I raised a question about the labeling on the key, I initially thought that it indeed indicated an entry order of exponent, base, operator in RPN. That seemed an awkward throwback to the original HP 35. You explained that it was only an arbitrary notation for exponentiation on the key. It could have been a simple ^.


Amen. I rest my case... ("but it moves!" Galileo-Galilei)


Edited: 18 July 2013, 3:03 a.m.

CAS: verification arguments

Error#0

makeList( x^2, x, 1, 5, 1 ) [Enter] return { 1, 4, 9, 16, 25 } OK

[Bug] makeList( x^2, x^2, 1, 5, 1 ) [Enter] return { 1, 2, 3, 4, 5 } ??

[ok] makeList( x^2, x^2, 1, 5, 1 ) [Enter] return "Error: Wrong Argument Type, The second argument must be a variable"

[Bug] makeList( x^2, x^2, 1, j, 1 ) [Enter] { } ??

[ok] makeList( x^2, x^2, 1, j, 1 ) [Enter] return "Error: Wrong Argument Type, The fourth argument must be a integer number"

Error#1
(+) [Enter] return a dialog box with (+) ??

[ok] (+) [Enter] return "Binary operator requires two arguments"

Request#0, view the elements of each list in separate lines for better visualization

iDivis( { -6, -4, 1,2,3,4, 5, 6, 7, 8, 9, 10 } ) [Enter] return

{
[ 1 2 3 6 ]

[ 1 2 4 ]

[ 1 ]

[ 1 2 ]

[ 1 3 ]

[ 1 2 4 ]

[ 1 5 ]

[ 1 2 3 6 ]

[ 1 7 ]

[ 1 2 4 8 ]

[ 1 3 9 ]

[ 1 2 5 10 ]

[ 1 11 ]

[ 1 2 4 3 6 12 ]
}


solve(3*a+b=5, b ) [Enter] Return { -3*a+5 } OK

best b=-3*a+5

Edited: 16 July 2013, 6:53 p.m. after one or more responses were posted


Please no telegraphic style.

Please note that we don't know what is your head, so a sentence or 2 is welcome.

Not exactly an error in the Prime, rather in the emulator. When language is set to "português", the calculator messages are displayed in Iberian Portuguese, but the Windows menus change to Italian:


Just for information, the emulator works great on Linux with Wine ;-)
I noticed some display problems with exponents, will do a report later.

Regards.

May not be an error, but when trying Gerson's Pandigital expression on the HP Prime (in algebraic mode) I got this:

Not anymore a pandigital expression but also exponents look strange, specially for 10^6 .


Quote:
Not anymore a pandigital expression...

To make it pandigital, you can use ALOG (either spelled out in ALPHA, or from the Toolbox catalog menu) instead of the 10^x key.

Thanks for the tip on the catalog. What I find strange for 10^6 is the relative size and position of the small subscript 10 and the big superscript 6 which seems to "fly" alone and not related to the 10, but I suppose this has already been reported by the beta testers and may already have been fixed.

Quote:
Marcus von Cube:

There seem to be some issues with RPN entry and the Function Applet. Try to enter a function such as SIN(X) while in RPN mode. RPN seems to be active even outside the home screen and interferes with symbolic entry.


Quote:
Tim Wessmann:

RPN works in these screens as well. 'SIN(X)' for an algebraic. Should it not work everywhere to the extent possible?


I tried X SIN (no quotes) which evaluated to 0 instead to SIN(X) as expected. X seems to be a defined variable in this context. The problem I see is that the command line is EVALuated completely and the result is copied to the entry field. This is impractical in my opinion.


Hi Marcus!

I don't tried a lot RPN mode but :

A..Z are predefined as real variables

'X' SIN

->

'SIN(X)'

X always return the value of X and never 'X' like on the 50G when when X is undefined.


If you compare the evaluation behavior to non-RPN mode there is a difference:

  • in RPN, X SIN is immediately evaluated to 0
  • in other modes, SIN(X) is entered as an expression and is not evaluated.

This is inconsistent in my view.

Edited: 17 July 2013, 7:52 a.m.


On the 50g, store a number into X. 0 'X' STO. This matches the predefined "real only" variables of A-Z,theta that exist in Prime.

Now type X SIN on the stack. You get SIN(0) evaluated. Do the same in the equation entry for the plotter. You get SIN(0) evalauted.

The entire concept of RPN (of any variety) is that evaluation always happens immediately except in a few well defined cases. If you do not want evaluation in the 50g, the ' ' is what triggers that.

'X' SIN in the plotter is how to enter an expression RPN style. Else, 'SIN(X)'. Both systems work identically here.

Edited: 17 July 2013, 10:10 a.m.


Tim, in the plotter's symbolic view X should always be considered a formal variable, never a defined numerical item.

RPN immediately evaluates entries while in interactive mode but I would not consider the filling of an entry field in a form being interactive mode.


It is a RPN command line though. Input is treated as RPN. The same holds true in the spreadsheet, dialog boxes, and any other place where input is allowed (excluding the CAS unfortunately). This is how the 49 and on has acted.

Having 1 area only act "algebraically" seems totally opposite of consistent. (hence the complaints about the CAS)

TW

Edited: 17 July 2013, 10:43 a.m.

In CAS mode: evalf (expression, precision) gives "Longfloat Library not available" :-( Probably not a bug, unfortunately; I guess this is deliberate. Do we know how much of xcas is implemented?

Nigel (UK)


Not a bug as you say. :-(

Key thing with that is to find an appropriately priced/licensed library that can be used, and to ensure RAM usage isn't too bad.

Basically, duplicates/synonymns have been reduced down to a smaller group of commands (to avoid having huge numbers of duplicate or near identical commands), the 3d rendering things and some other plots that will require more work, some of the more exotic commands, commands that ouput data files (like converting an expression to an html file), the "compatability" syntax for various systems, "ui specific" things that are really UI specific to the xcas intrface (the interactive ode window for example), and the longfloat stuff.

Simply because a function isn't there now doesn't mean it won't ever though. Basically, comes down to this question: Is it better to have a buggy and less tested system with more functionality, or have one that is stable, well tested, and well documented? :-)

TW


Edited: 17 July 2013, 11:28 a.m.


TW and Patrice,

I started going through the 'on-calc' Help system, and I noticed typos and grammatical errors. Is someone at HP going to be cleaning this up? Has it already been cleaned up? Should I continue?

Here is what I found after about 15 minutes of browsing, starting at the top of the Help tree:

Help > Main Help > line 11: 'left' is spelled 'ley'.
Help > Main Help > line 27: 'whatever' should be 'which'.
Help > Home View > line 10: 'functions' should be 'function'.
Help > Home View > line 20: 'later' should be 'other'.
Help > Home View > line 26: 'he' should be 'the'.
Help > Home View > line 27: 'by tapping twice on it' should be 'by tapping it twice'.
Help > Home View > line 33-38: first two bullet items have no '.', the third has a '.'.

Help > Keys > 'Press the key you want help on' should be 'Press the key you want help for'

Also, I noticed in the Geometry App, after selecting an object to draw, say for example a Circle, a label in the top-left says 'Hit Center'. Shouldn't this say 'Tap Center' to go along with conventions found in Help. ('Tap', 'Press', etc)?

Please tell me these have been/will be cleaned up by an English major. (Note: I am not an English major).

Thank you,

PG

Edited: 17 July 2013, 1:36 p.m.


Quote:
I started going through the 'on-calc' Help system, and I noticed typos and grammatical errors. Is someone at HP going to be cleaning this up? Has it already been cleaned up? Should I continue?
The help system has already been greatly overhauled; you're looking at obsolete help screens. Most of the typos and brainos you mention have already been corrected.

Hit versus Tap: tapping isn't the only way to set a point in the Geometry app; you can also press the Enter key after moving the arrow with the cursor keys. But I agree with you that "tap" sounds better here than "hit".


Quote:
Most of the typos and brainos you mention have already been corrected.

Good to hear. Thanks, Joe..

Thanks for this answer. I agree: I'd rather have a device that is (relatively) bug-free at launch even if this means limiting its features somewhat. For now, I can use the WP-34S in double precision mode if I ever need 30 significant figures!

Nigel (UK)

Please
http://www.bugzilla.org/

My review

http://www.adictoshp.org/topic/350-emulator-review-hp-prime-virtual-calculator-on-pc/


Edited: 17 July 2013, 4:58 p.m.


bug reported for list2mat

Three comments after playing with it for a few minutes.

- Pressing "Alpha" once enables Alpha for one key, pressing it twice enables it for all following keys; but the annunciator stays the same. It would be nice if there were two different annunciators for "Alpha" and "Alpha-lock".

- The visual difference between "menu buttons" and "command buttons" is easy to miss. Just squaring the top corners isn't enough in my opinion. I would either make them two different colors, or make the text of menu buttons bold, or I'd add a graphical icon to the menu buttons, or something like that, to better differentiate them.

- In the character screen, it would be nice if a double-tap would actually echo the character, that would be quicker than having to tap the character and then "echo" for each character to enter.

Edited: 17 July 2013, 3:16 p.m.


You're actually the very first person to say anything at all about the alpha lock indicator.


Tim,

I don't do a lot of responding to this group. I mainly read and try and gain insight from the rest of the group. I am a drafter by trade and use the 48GX for work. Mostly for unit conversions. I have mot spent a lot of time with the Prime emulator but have a real problem with the unit converter. On the 48GX, I can covert units with 3 to 4 key strokes after I enter the number I am converting from. Using the examples in the Primes guide this process takes about 12 key strokes for the simplest conversions and it has to be done with each number you want to convert. Please tell me that there is a flag that can be set like on the 50G that allows for 48 style unit conversions?


Can you show a couple key strokes examples with 50g and how you do the same with Prime.


Hi Patrice

I agree with Richard here.

A simple exemple to convert kph -> mph

RShift Unit Speed
100 Softkey kph

Display : 100_kph

LShift Softkey mph

Display : 62,137..._mph

What is very interesting with the 50G is the LShift_SoftMenuUnit to change from one unit to another in two keystrokes ( more if the soft menu is not displayed)

No, there is not.

There is a design for a really slick unit conversion utility/capability, but it did not make the cut for first release.

Some people get super excited about the 48 style unit conversion, but in all honesty it only does *one* thing well - simple conversions of the same unit type. Once you start doing anything slightly more complex, it pretty much falls apart. It doesn't work well for complex units, manipulating units, or modifying units.

Now that basic conversion is a large amount of what units get used for, but anyone who can't imagine any way that can be improved or extended and holds it as the pinnacle of unit interactions needs to fire up the imagination a bit more. :-)


This is just out of curiosity (and may be already so on the 50) - why use the "MKSA" term for the SI? Yes I know about the main units, but its international name is a better choice IMHO.


Edited: 18 July 2013, 6:14 a.m.


Ask Bernard. :-|

When you are trying to combine two different systems it gets problematic quickly.

Edited: 18 July 2013, 10:27 a.m.


I think it is not about 2 systems.

It is rather 1 system, 2 names, 1 name being based on the units 'MKSA', the other name being 'International System' or 'SI'.

And about which name to use.

Edited: 18 July 2013, 12:15 p.m.


The two systems I was referring to here was not the units, but rather xcas and the hp software.

TW

Edited: 18 July 2013, 1:41 p.m.

Quote:
There is a design for a really slick unit conversion utility/capability, but it did not make the cut for first release.

.. basic conversion is a large amount of what units get used for..




Is the slick, new units conversion capability near the top of the list for the second pass? If not, may I please put in a vote that this be made a top priority?



I'm glad you said it, because I agree that basic conversion really is a large amount of what units get used for - it's something calculators do very well! If there are plans for an exciting new design for unit conversions, that's great, but not having a short and simple (read: minimal keystrokes) method of doing basic conversions out of the starting block, is, IMHO, a missed opportunity for something that a mid-to-high level calculator should shine at doing.


Honestly, the first thing that entered my mind after reading the unit conversion steps that Richard and Gilles described above, was the poorly implemented Base conversion methodology used on the 35S. I realize the 35S was developed by a contractor to HP's spec, but that isn't the case at all for the Prime. The sooner the slick, new units conversion functionality is in, the better, but please, not at the expense of a fast and direct basic units interface. If not for us, do it for the kids (that you're marketing the Prime to). ;-) It's a pretty big deal Tim.

Edited: 19 July 2013, 1:56 a.m.

I disagree - as posted earlier the 39gII has a terrible time with unit math compared to the 50g and even the TI CX implements better unit handling.


How so? You have to dig through a menu to get the units on both (unless you type them in directly).

TW


But the nSpire CX handles unit math correctly:

What is the diameter of a sphere of 100lbs of Uranium at 19.05 g/cm^3?

nSpire CX:
2 * Ctrl n_root_x 3 right_arw
( 100_lb / (19.05_gm/cm^3) right_arw right_arw right_arw
* 3 / 4 / pi

Units Convert _in enter

gives you 6.52264_in

You have to arrow around to pick units, but you can use left and right arrow to open/close categories, picking units pretty easily, and it handles /_cm^3 correctly, and does the cube root on _m^3 correctly. Plus conversion works easily.

Solve the problem on an HP Prime or 39gII?

Edited: 31 July 2013, 8:32 p.m.


Just a simple example of how quickly the 39gII annoys:

100_lb / ( 19.05_g / 1_(cm^3) Enter

yields 5.249344_(lb*g^(-1)*cm^3)

which is an annoying result.

BTW, can't see a smooth way to enter 19.05_g/cm^3 so had to go with extra math to compute the unit, though having (cm^3) in Volume is nice.

Quote:
You're actually the very first person to say anything at all about the alpha lock indicator.

Hi Tim,
I'm not sure what you mean... does my idea not make sense? :)
I know that older calculators don't have the "lock" indicator either, but those had "custom icons" on the LCD, so this would have needed another dedicated icon. While here everything is done in the graphic matrix, so it should be easy to add the feature. Of course it's not a big deal - if you don't remember what "mode" you're in, just start typing a character, and see if the indicator goes away, in which case just re-enter Alpha mode. I just thought it would be nice! :)


No, I thought it was good as well and put this in yesterday. Basically, removes the ..., scoots the letter over 1 and puts the arrow used for the user lock and shift.

Was just saying that nobody had said anything about it. It is often very surprising to me the things that some people spot immediately that nobody else has ever commented on.

TW


One wish for the emulator:

It would be nice if the PC-keys <Del>, <Home> and <End> would work as expected on the command entry line.

I know it could be done with <Ctrl><BS> and <Ctrl><Left>/<Right>, but the single keys would be a bit more comfortable.

PS: The same for <PgUp> and <PgDn> as abbreviation for <Ctrl><Up>/<Dn> for the entry history.

Franz

Edited: 18 July 2013, 10:51 a.m.


Good suggestions. Will put them in.

The main reason they aren't there is that I develop mostly on a laptop and don't have those buttons, so they didn't even occur to me! :-)


Quote:
The main reason they aren't there is that I develop mostly on a laptop and don't have those buttons, so they didn't even occur to me! :-)

OMG, that must be an old laptop. ;-)

BTW, there's another problem especially on German (maybe also on other non-US) keyboards:

A few characters like {[]}\|~@ can only be accessed on such keyboards with the <AltGr> key. But the emulator interprets this <AltGr> key as <Ctrl> and activates the calcs 'Shift' key, so these characters can't be entered in an easy way.

Maybe there's a possibility for the emulator to differentiate between the <Ctrl> and the <AltGr> key, so that only <Ctrl> will activate 'Shift'!?

PS: and one more glitch:

The <Ctrl> key on the PC keyboard (which is 'Shift' on the emulator) has a repeat function, i.e. if you press <Ctrl> a bit longer then this 'Shift' function on the emulator switches on and off. I would say this should be changed, because usually you press <Ctrl> and the following key on the PC at the same time, and with this repeat function it's often a problem (when you hold the <Ctrl> key a bit too long).

Franz

Edited: 18 July 2013, 1:23 p.m.


Feel free to change it. The skin file has the keymapping.


Quote:
Feel free to change it. The skin file has the keymapping.

Well, of course I've already looked at these skin files, but what I described is not possible by changing the skin files. :-(

As I understand this 'key=...' structure you can only assign any PC key to each of the calculator keys, but not the other direction. What would be needed for this problem with non-US keyboards is to prevent the emulator from taking the <AltGr> key as <Ctrl> (=Shift) key, and that's not in the scope of the skin files.

An other possibility would be to let one PC key execute 2 calculator keys (e.g. [Shift]+[8] for {} or [Shift]+[5] for []), but that's also impossible in the skin file.

All I want is just that the emulator does not handle the <AltGr> key the same way as the <Ctrl> key.

Franz

Edited: 18 July 2013, 2:01 p.m.


If it generates the same keyboard code, I can't do anything about it right now. Sorry.

Edited: 18 July 2013, 2:26 p.m.


Quote:
If it generates the same keyboard code, I can't do anything about it right now. Sorry.

Since Windows handles <Ctrl> and <AltGr> in a different way, there must be a method to distinguish between those 2 keys. But of course that may depend on the programming language and its possibilities for checking the keyboard status.

I've now looked at my KML scripts for Christophs HP-Emus, and <Ctrl> has scancode 17, <AltGr> Scancode 18.

Franz

Edited: 18 July 2013, 3:31 p.m.

The laptop was probably a macbook pro. None of the page control keys like that.


Actually, the Macbook Pros/Airs do have those keys (sort of). They are just masked by the requirement of using the fn key.



Page Up: FN UP arrow

Page Down: FN Down Arrow

Home: FN Left Arrow

End: FN Right Arrow



Forward Delete: FN Delete



You probably already know this, but, then again, I know a lot of people who are experienced Macbook users who weren't aware of this functionality.



Regards,

Mark

Quote:
You're actually the very first person to say anything at all about the alpha lock indicator.

@Tim @Cristian
Yesterday, reading this message, maybe before Cristian, I was going to ask: "Tim, is this a bad or a good thing, I mean a compliment or a complain?".....then I thought ...it's more correct let Cristian the rethoric question.....

But today, reading this post and your comments about, believe me I've not yet completely understood what Tim means..I think this is due to my age.....soon I'll need a calculator even to remind it=:)

Edited: 18 July 2013, 4:46 p.m.

a picture says a thousand words/una imagen dice mas que mil palabras




Edited: 19 July 2013, 9:21 a.m.


Hi Compsys

In your 'Prime' examples, a,b,c,d _are themselves_ considered as complex numbers ( that mean a=f+g*i etc.)

You must uncheck 'complex' in CAS setting if your want your variables to be real only

re(e^(Pi*i/5)) and non text book are bugs of that old pre release

Edited: 19 July 2013, 9:59 a.m.


Hello

Use the letter e, i as mathematical expressions, disabled using variables e, and i, why not use another character e, i in italics, bold for example?

TI_Derive




Edited: 19 July 2013, 12:33 p.m. after one or more responses were posted


I agree with you about this

Your point about

'(a+b.i)/(c+d.i)' wich becomes automatically on the TI
'(a*c+b*d)/(SQ(c)+SQ(d))+(b*c-a*d)/(SQ(c)+SQ(d))*i'

is interesting ...

Is this really a good thing ?

By the way Simplify don't do the job on the Prime neither EVAL on the 50G. We must use RE and IM to get the imaginary and real part of the complex expression.

With the 50G a small prg like
<< DUP RE SWAP IM i * + >>
we can affect to a user key does the job

PS : The funny thing is that the 50G simplify exactly on the contrary :

'(a*c+b*d)/(SQ(c)+SQ(d))+(b*c-a*d)/(SQ(c)+SQ(d))*i'
Simplify
'(a+b.i)/(c+d.i)'


Result on the Prime when disallow complex varaibles :

There are no automatic simplication of complex in real+Imaginaire*i


Edited: 19 July 2013, 11:02 a.m.


Quote:
'(a+b.i)/(c+d.i)' wich becomes automatically on the TI '(a*c+b*d)/(SQ(c)+SQ(d))+(b*c-a*d)/(SQ(c)+SQ(d))*i'

is interesting ...

Is this really a good thing ?


Sorry for my bad English

By default a calculator should calculate, or make algebraic operations G + G [Enter] 2G

HP-Prime G + G [Enter] G + G =(

and for a flag to disable the calculation of expressions, like fx-cp400


worn at all times [simplify] is cumbersome, much time is lost, nothing didactic, confused, etc.

Edited: 19 July 2013, 12:51 p.m.


I like the way the 50G does : no automatic simplification (evaluation). I'm the operator with my pocket calculator (Kraftwerk ;) and I choose if I want to simplify, factorise, linearise etc.

With the 50G you can simplify (factorise, linearise ... ) sub-expression and manipulate very easily math expression, move what you want at the beginning of the expression or at the end etc... And in general my math expressions in RPL results of combination of other expressions. I always think that RPL is a marvelous tools for manipulate algebraic expressions.

And it's not more keystroke in RPL because a command don't need ENTER key... And EVAL can be use instead ENTER

But I agree if this is obvious for me in RPL (the calculator don't have do what you don't ask it to do), it's not so obvious with the Prime CAS wich is purely algebraic.

In fact it would be interesting to compare the way to do of different calcs with real and non trivial exercices.

The idea of a flag to enable/disable automatic evaluation is interesting.


Edited: 19 July 2013, 5:29 p.m.


Bug with e.^(Matrix)versus e^(SqMatrix)

/!\ (.^) =/= ^
(./) =/= / etc

using only the operator (^)
TI89/NSPIRE e^( [[ 1, 2 ],[ 3, 4 ]] ) [Enter] direct answer [[ 51.9... 74.73],[ 112.1 164.0 ]] OK

HP-Prime e^( [[ 1, 2 ],[ 3, 4 ]] ) [Enter] return [[....]] OK approx(ans) [[ 51.9... 74.73],[ 112.1 164.0 ]] OK =)

Now using the operator (.^)
TI89/NSPIRE e.^([[ 1, 2 ],[ 3, 4 ]] ) = [ [e^1, e^2],[e^3, e^4]] OK

[Bug#?] HP-Prime e.^( [ [1,2],[3,4]] ) [Enter] return
[[ 51.9... 74.73],[ 112.1 164.0 ]] Error

[Request]:

#0
Please new alternatives of input for matrix

[[1, 2],[3, 4]] == [ 1, 2; 3, 4 ]

#1
Please flag for disable and enable automatic evaluation

automatic evaluation = natural and direct answer =) Especially for students beginners


Edited: 20 July 2013, 10:18 p.m. after one or more responses were posted


[[1,2,3],4,5,6,7,8,9]

However, considering that you think RPN should not evaluate when the user types 1 2 + but must type 1 2 + ENTER, I suspect that you are not familiar with this entry style.

Also, you seem to be indicating that the prime - which DOES give you the symbolic solution for that matrix e^[[1,2],[3,4]] - is somehow in the wrong on not being as helpful. Please demonstrate how to get that symbolic result on the nspire. :-)

The point is, right now the CAS makes no assumptions about how the result should be formatted. Automatically assuming the "correct" format means that for certain people it is good, but for others is useless.

TW


Edited: 20 July 2013, 6:18 p.m.


the previous bug is that e (.^) matrix should calculated for each element of matrix, note e^(sq-matrix) OK

TI89/nspire e^( [[ 4, 2, 0 ], [ 1, 4, 1 ], [ 1, 1, 4 ]] [Enter] return "Error: Matrix not diagonizable" =(

fx-cp400 e^( [[ 4, 2, 0 ], [ 1, 4, 1 ], [ 1, 1, 4 ]] [Enter]
return "Undefined" // =(

HP-Prime e^( [[ 4, 2, 0 ], [ 1, 4, 1 ], [ 1, 1, 4 ]] [Enter]
return a matrix // OK

[Bug#?] HP-Prime e^( [[ 1 ], [ 2 ]] ) [Enter]
return [ e^1, e^2 ] a vector why? // Bug, should check if the array is SQUARE first, before calculations

above is valid when used (.^)
e.^( [[ 1 ], [ 2 ]] ) [Enter] [ e^1, e^2 ] // OK

[Bug#] Max( complex Number, Complex Number ) must return
"Can not be compared complex number" for maximum, Bug on HP & TI

// Inf name, is not textBook, please to use oo symbol

[Request]:
#3 Recalling a help text for each output, as does the calculator TI-nspire

#4 rename Algebraic input mode by Linear or 1D

more on direct answer and BUGs

Hay que estar usando comando de agrupacion, simplificacion, etc para ver las respuestas, con un flag de auto-simplificacion se evitaría esto

En la factorizacion siguiente (1er ejemplo) la respuesta es correcta pero se invierte ( b ) con (y), el CAS no esta organizando bien la variable y para mi esto es un BUG informático o no?

En la gráfica anterior el cursor esta muy pequeño, cuando anteriormente hay un exponente, esto es un BUG, pues da ha entender que el cursor va ha editar a (y) y no al exponente

Edited: 22 July 2013, 5:14 p.m. after one or more responses were posted


[Bug#?] HP-Prime e^( [[ 4, 2, 0 ], [ 1, 4, 1 ], [ 1, 1, 4 ]] [Enter] return a matrix why? // Bug, should check if the array is diagolizable first, before calculations

Nope. Just more capable then the other 2 units. ;-) http://www.wolframalpha.com/input/?i=matrixexp%28+[[+4%2C+2%2C+0+]%2C+[+1%2C+4%2C+1+]%2C+[+1%2C+1%2C+4+]]%29+


[Bug#?] HP-Prime e^( [[ 1 ], [ 2 ]] ) [Enter] return [ e^1, e^2 ] a vector why? // Bug, should check if the array is SQUARE first, before calculations

Nope, for the same reason that sin(1,2,3,4,5,6) is a valid command in Prime.

[Bug#] Max( complex Number, Complex Number ) must return "Can not be compared complex number" Bug on HP & TI

Don't think so. This might be why. http://mathworld.wolfram.com/ComplexModulus.html

[Request]: #3 Recalling a help text for each output, as does the calculator TI-nspire

???


Errr... no




There is no total order relation in the field of complex numbers. e.g.




http://en.wikipedia.org/wiki/Ordered_field




You can define a partial order relation, but that's all. You can order them according to their modulus, but what about their arguments? Which is the "proper" ordering?... None.




The point of an educational device is not to teach wrong things about Mathematics. The TI fails here as well.




No elementary courses deal with functions of non-diagonalisable matrices. You can do it, but is it worth it at this stage? I seriously doubt it.

Edited: 21 July 2013, 9:12 a.m.


Fully agree - complex numbers are not an ordered domain!

The 41Z has the following comparison tests:

UNIT? - is |z|=1?

OUT? - is |z|>1?

IN? = is |z|<1?

z=0?
z=i?
z#0?
z#i?
z=w?
z#w?

but nothing else...

Cheers,
'AM

Just sorry to disagree about the point regarding non diagonalisable matrix. This just a particular case of matrix in general. The exponential of matrix is used in particular for computing the solution of a linear differential equation (in state vector representation) and cases where the matrix has not a diagonal representation are fairly common. Using the diagonal form for computing the exponential is just a 'trick' but not a general solution. In this respect the approach of the 'prime' is quite good.
My 2 cents...


The matrix exponential is defined only for square matrices

http://www.wolframalpha.com/input/?i=matrixexp%28+%5B%5B+1%2C+2+%5D%2C+%5B+2%2C+3+%5D%2C+%5B+4%2C+5%5D%5D%29+

[HP-Prime] e^( [[ 1, 2 ], [ 2, 3 ], [ 4, 5] ) [Enter] return [[ e^1, e^2 ], [ e^2, e^3 ], [ e^4, e^5] // BUG =(

the above result is only valid with the command (.^)

[HP-Prime] e.^( [[ 1, 2 ], [ 2, 3 ], [ 4, 5]) [Enter] return [[ e^1, e^2 ], [ e^2, e^3 ], [ e^4, e^5] // OK

/!\ (.+ .* .^ .-) HP-Prime commands created for the purpose: operating point/element to point/element

sample

Matrix1(n*m) * Matrix2(n1*m1) = matrix3( n*m1)// with m=n1

Matrix1(n*m) .* Matrix2(n1*m1) = Matrix3(n*m)

///

In the factorizations are not sorted the variables, see image above

///

Request# Please a new command Magic_square

http://en.wikipedia.org/wiki/Magic_square

Edited: 21 July 2013, 6:21 p.m.


>[HP-Prime] e^( [[ 1, 2 ], [ 2, 3 ], [ 4, 5] ) [Enter] return [[ e^1, e^2 ], [ e^2, e^3 ], [ e^4, e^5] // BUG =(

No, this is not a bug. It is an minor inconsistency at most, but is by design.

In the prime cas (as in xcas), any cas function can take any number of arguments. This means that sin(1,2,3,4,5) is a perfectly valid operation which returns a vector of results. e^[<square matrix>] has been defined as such that it is a shortcut to the matrix exponential function.

If the matrix is not square, then it drops back to default handling and applies the function to any value in the vector. There is not a matrix object in the CAS. Nearly all professional type cas systems do not have a distinction or separation between matrices/vectors/lists. They are usually the same object.

This can unfortunately be annoying sometimes to users that are used to having clear and complete separation between the objects. There is not that distinction here.

Personally, I would prefer to eliminate the shortcut so it would be more consistent. I am not king of everything though. :-)


If it is a mistake/error or bug

For that there is the command .^ that perform unconventional operations

Parallel programming is accepted

sin ({a, b, c, etc}) = { sin(a), sin(b), etc } else is scrambling mathematical concepts

e^( NO square matrix ) // error dimension

e .^ ( Square or rectangular matrix ) // ok

otherwise remove the command .^ of catalog

Edited: 21 July 2013, 10:26 p.m.

I said elementary... but if you want to deal with linear systems, you're absolutely right.

Compsys, It's curious that you call the 'approx' answer of the TI a 'direct' answer. The HP gives the exact answer because you just ask for this by taping ENTER. Why the TI returns an approx result here is myterious.

Why the TI choose to return sometimes an exact and other time approx result ?

If you want an APPROX result on th HP, use the APPROX key (Shift ENTER)

I'm curious what the TI will return here with a symbolic matrix here ?

It seems that the HP applies most functions to matrix without need of MAP. Here with the e^ .It's very ambigous because it seems to return e.^ when e^ is not caculable. In my opinion it s a very bad idea in this special case of the exponential function

I notice the same behavior with the Square Root function : The HP returns a square root of the matrix or the square root of each element of the matrix depending of the context. Like the exp function this is disconcerting and I think it must be changed. A function apply to an object (number, matrix, list...) must have only one signification. I hope HP to correct this.

EDIT :I saw the message of TIM above. I dont know who is the king for this ;) , but it's not reasonable that a unique function for an object (here a matrix) does one thing or another thing depending of things you don't know à priori. And I'msure that a matrix in not a list : I see one between {} and the other between [] ;)


Edited: 21 July 2013, 8:49 p.m.


If the argument has ., Is forced to respond in approximate mode


Quote:
If the argument has ., Is forced to respond in approximate mode


No point here ...


Updated image above, you can check it using computer software

http://education.ti.com/en/us/products/computer_software/ti-nspire-software/ti-nspire-and-ti-nspire-cas-teacher-software/tabs/overview


I don't understand what you are saying here ...

On Prime :

exp([[1. 2.] [3. 4.]]) ENTER

returns an approx answer

exp[[1 2] [3 4]] ENTER returns an exact answer

exp([[1 2] [3 4]]) Shift ENTER return an approx answer

I don't see any update in the imae above
By the way how can you have 2 differents images with the same function calls ?


Edited: 22 July 2013, 9:13 a.m.

Hi CompSys

could you please post news messages instead of edit the same old one...

A..Z variables are predefine and stricly numeric on the PRIME

All your examples works with Prime with 'simplify'

What about factor(c*b*a+y*b*a+(y*c*a+y^2*a)+(y*c*b+y^2*b+(y^2*c+y^3))

on the nSpire ?

Edited: 21 July 2013, 4:44 p.m.


[HP-Prime] (b+c*i)^-1 [Enter] return (b+c*i)^-1 =(
evalc(ans) [Enter] return b/(b^2+c^2) - c/(b^2+c^2)*i OK

For every answer of HP-Prime must be simplified, evaluated, etc then all the speed of his processor is lost =( =[

[HP-Prime] (c+d*i) + (g+b*i) // sum of complex numbers [Enter] return (c*d*i) + (g+b*i)
evalc(ans) [Enter] return ok

Edited: 22 July 2013, 5:43 p.m. after one or more responses were posted


direct answer AUTO-SIMPLIFY

In spanish =(

HP esta aun paso de tener la mejor calculadora del mundo, pero ...

Primero pensemos a quien esta destinado este producto HP-Prime, según he leído se enfocara en el campo educativo, estudiantes entre 12 y 18 años, es asi o no? o es para estudiantes de ingeniería y profesionales?

Que debe cambiar o mejorar

1: Tal ves lo mas importante, las respuestas deben ser lo mas simples, es decir si el usuario por ejemplo suma dos letras (a + a) debe retornar el calculo, osea (2*a) no hacer un eco de la entrada, este es un ejemplo trivial, pero es análogo a otros

si el usuario desea sumar dos polinomios (x+3) + (x^2+4*x) entonces la calculadora debe calcular, valga la redundancia a x^2+5*x+7, y no replicar la entrada en la salida, para luego ejecutar simplify(ans) u otro comando, ESTAN DE ACUERDO O NO?

Tim Wessman escribio que si se hace esto, se pierde el control sobre las expresiones, esto es verdad, es mas las calculadoras Texas Instruments tienden a dar respuestas directas, que es lo mas natural, pero que innovate CASIO con la serie classpad, tiene un FLAG o bandera que permite desactivar o no las respuestas directas o simplificación automática, asi todos contentos, y no pienso por mi, si no por los estudiantes que están aprendiendo matemáticas, y que mejor una buena herramienta educativa que les ayude a comprender mejor los conceptos

Si no se realiza simplificación automática, o mejor llamemoslo mejor respuesta directa, se genera confusion dando expresiones complejas, largas, difíciles de comprender para "ojos" no expertos

otro ejemplo suma de numeros complejos

[HP-Prime] (c+d*i) + (g+b*i) // sum of 2 complex numbers [Enter] return (c*d*i) + (g+b*i) // a simple vista que piensa el estudiante, que la calculadora no "puede" sumar números complejos, pues la entrada es igual a la respuesta

Ahora para simplificarla o agruparla hay que usar comandos a cada momento comados especializados =(
evalc(ans) [Enter] ok

otro ejemplo

[HP-Prime] (b+c*i)^-1 [Enter] return (b+c*i)^-1 // igual realizo un eco =(
evalc(ans) [Enter] ok

El CAS en las calculadoras HP, nació con ALG48 http://www.hpcalc.org/details.php?id=1320

Hace mas de 10 anios, realice una biblioteca CAS48 que se apoyaba en ALG48, y que expandía el numero de funciones y comandos de ALG48, si abren el código, verán que en cada subrutina utilizaba EXPAND and SIMPLIFY para poder manipular las expresiones y hacerla mas amigable al usuario =)

http://www.hpcalc.org/details.php?id=1337

http://www.hpcalc.org/details.php?id=1336

Edited: 22 July 2013, 6:05 p.m.

The command for regroup an expression in RE+i*IM is evalc()

I suggest [evalc] to be in the soft menu like [simplif]

In a more recent version that the pre-release there is no need to press [simplif] 'Shift' 'ANS' for simplify a result. Tap only [simplif] (one keystroke) is OK


Quote:
A..Z variables are predefine and stricly numeric on the PRIME

I accept, but not the lowercase e, i =(

Quote:
I suggest [evalc] to be in the soft menu like [simplif]

+1

[HP-Prime] (b+c*i)^-1 [Enter] return (b+c*i)^-1

evalc(ans) [Enter] return b/(b^2+c^2) - i*[c/(b^2+c^2)] OK

Request #?: a flag to display the imaginary unit at the end or beginning, now sometimes this right and other left

[HP-Prime] (b+c*i)^-1 [Enter] return (b+c*i)^-1
evalc(ans) [Enter] return

b/(b^2+c^2) - (c/(b^2+c^2))*i // Flag On

b/(b^2+c^2) - i*(c/(b^2+c^2)) // Flag Off

Request #?: rename evalC to evalCplx more intuitive =)

Request #?: i /=/ i that technical difficulties exist?

same e /=/ #e

idea use char #234 = ê = e^ Good idea?

#239 = ï = #i


Edited: 23 July 2013, 10:29 a.m.

Notes after a 30 minute play with the emulator...

* [neg] Unit conversion is a step back from the HP50g. It's just not good anywhere in the same league of usability.

* [neg] When I throw my 50g in FIX 2, it formats the numbers 123,456,789.00 rather than 123456789.00 on the prime.

* [neg] Took ages to find the boolean operators.

* [pos] Factorial is less hidden than the 50g.

* [neg] * as the product operator is really ugly. I'd expect a dot these days as per the nSpire. To be honest, the output looks like an anti-aliased TI84-series attempt at showing natural/textbook input. Some real polishing needs to be done here.

* [neg] STO> doesn't work in RPN mode very well i.e. if you enter 12 'U' on a single line and whack sto, it drops the arrow in rather than executing STO. This is inconsistent with other RPN operators.

* [pos] It has help!

* [neg] Not 100% sure how to see what is assigned in the current scope (as per VAR menu in 50g).

* [pos] TVM/Amortization rocks - well done :)

* [neg] Few CAS bugs as discussed in other places on this thread.

Edited: 20 July 2013, 5:33 p.m.


* [neg] Unit conversion is a step back from the HP50g. It's just not good anywhere in the same league of usability.

Indeed. It is essentially the same as what you have ever had on any ti unit (except with more units), and leagues above any casio. Hence, when it came time to prioritize what did and didn't get done for first release the units slipped out. There is just so much possible now that we have a touch interface to make hard things simple...

* [neg] When I throw my 50g in FIX 2, it formats the numbers 123,456,789.00 rather than 123456789.00 on the prime.

The issue here basically boils down to trying to find a way that works universally through the system. The CAS does not support decimal settings nor separators. We want any solution here to be one that works correctly everywhere-not just in the numerical side...

* [neg] Took ages to find the boolean operators.

Assuming once you did, the location makes sense? (for those wondering, they are in the popup menu with the less then, not equal and so on on the shift-6)

* [neg] * as the product operator is really ugly. I'd expect a dot these days as per the nSpire. To be honest, the output looks like an anti-aliased TI84-series attempt at showing natural/textbook input. Some real polishing needs to be done here.

Again, the issue here comes to trying to combine the CAS and the non-case systems. Bernard's CAS doesn't accept the dot operator, and really is designed for keyboard input text only. A clean solution that doesn't introduce a huge number of unintended consequences has proven very tricky to do.

* [neg] STO> doesn't work in RPN mode very well i.e. if you enter 12 'U' on a single line and whack sto, it drops the arrow in rather than executing STO. This is inconsistent with other RPN operators.

The RPN on that early release was not fully complete. It works basically identically now to the 50g with some improvments. For example, you can inline 2d expressions in the input. It also correct recognizes when you are inside an alg region instead of like the 50g where you type 1 '2' 3 and then + will not execute immediately (since you turned on an algebraic at some point earlier).

* [pos] It has help!

Really good help too! (and much better later once complete) Not sure if that has the ability to search and the examples/related commands at that point.

* [neg] Not 100% sure how to see what is assigned in the current scope (as per VAR menu in 50g).

There is no idea of "scope" or folders at this point. Variables created in home or the cas are global. Only limit on scope would be variables created in an application program file. Those would only be visible or active when that app is the currently running one.

* [pos] TVM/Amortization rocks - well done :)

Yeah, that is quite nice (pretty much directly pulled over from the 39gII). Would like to be able to do a lot more in the finance app at some time. Lots more good stuff could be done there with cash flows and similar.

* [neg] Few CAS bugs as discussed in other places on this thread.

There have only actually been 5 bugs of any kind discovered on any forums I've been watching (the list2mat thing, a few integrals from a Chinese forum that behaved badly). All are now resolved. The main (loudest?) complaint is the one regarding "does the cas auto-simplify or not?" is not a bug but really a difference of opinion - and of course that issue is being looked at heavily.

TW

Edited: 20 July 2013, 6:09 p.m.


Quote:
The main (loudest?) complaint is the one regarding "does the cas auto-simplify or not?" is not a bug but really a difference of opinion - and of course that issue is being looked at heavily.

And this complaint is absolutely understandable!

I know almost every existing CAS and none of them doesn't auto-simplify - applying at least the most obvious simplification rules (like e.g. combining terms with the same variables).

Show me one single CAS user (ok, except you ;-)) who wants to enter expressions like 2x+3x, 2x*3x or (6x^2)/(2x), and all he gets after pressing [ENTER] is a simple echo of his input without any change (i.e simplification) at all?

Sorry, but that's the most stupid idea I've ever seen in any software development - and if the real HP-Prime would behave that way I would definitely never buy such a calculator.

Franz


>Show me one single CAS user (ok, except you ;-))

Not I.

The CAS software author...

TW

Edited: 20 July 2013, 6:51 p.m.

Hello Franz,

I use the hp50g since three years and it's okay that kind of behavier.
For more complicate inputs you have the opportunity to control whether it is right key-stroked in or not.

It is indeed a point of view in usage, like TW says, there is no right or wrong.
So be calm, the market will tell the hp calculators group wether it's a good decision or not.


Greetings
peacecalc


Hi peacecalc,

Quote:
For more complicate inputs you have the opportunity to control whether it is right key-stroked in or not.

After pressing [Enter] you already see your input (and can check if it's correct) on the left column. The right (output) column is just a 1:1 copy of the input, so what's the use of seeing exactly the same expression twice on the screen??

But maybe there's a very clever idea behind this: you could train your eyes so that your left eye looks at the input (left side) and your right eye on the identical output (right side), and so you could see the expression in 3D/stereo!? ;-)

Quote:
... the market will tell the hp calculators group wether it's a good decision or not.

Well, I would say the market (users) have already told their opinion in different forums: the overwhelming majority does not like a completely unsimplified output, i.e. to get just an echo of the input.

At least an option to set Auto-Simplify ON/OFF should be added ...

For TW: it would be nice to have an extra symbol for indefinite integration (without lower/upper limits) in the math-template (there's still one place free).

Franz


Edited: 21 July 2013, 6:22 a.m.

"Show me one single CAS user (ok, except you ;-)) who wants to enter expressions like 2x+3x, 2x*3x or (6x^2)/(2x), and all he gets after pressing [ENTER] is a simple echo of his input without any change (i.e simplification) at all?"

The 50G (in RPL,i never use algbraic mode) works like this and in real life I never found this was a problem.

But on RPL after pressing [Enter] you don't see your input on the left column... And EVAL works with to need push ENTER before

Also note that

(6x^2)/(2x)

is not the same as

3*x

Edited: 21 July 2013, 2:50 p.m.


Quote:
Also note that

(6x^2)/(2x)

is not the same as

3*x


Not? And why does then [simplify] reduce it to 3*x ? ;-)

Well, for x!=0 it IS the same, and for x=0 it isn't defined at all (and thus useless).

Franz

Edited: 21 July 2013, 4:30 p.m.


In the first case f(0)=0
in the second case, it's undefine

Decide to simplify is not the same than automatic simplication
It's a good example where auto simplification could have a border effect.

I'm lost in the messages of Compsys but I like the Casio (or TI) idea that you can choose i or j for the imaginary part of complex numbers and that the i (or j) are special characters.

Edited: 21 July 2013, 5:53 p.m.

Firstly, thanks for your reply. It's rare to get this sort of feedback on any product development!

Quote:
* [neg] Unit conversion is a step back from the HP50g. It's just not good anywhere in the same league of usability.

Indeed. It is essentially the same as what you have ever had on any ti unit (except with more units), and leagues above any casio. Hence, when it came time to prioritize what did and didn't get done for first release the units slipped out. There is just so much possible now that we have a touch interface to make hard things simple...


So we can expect some improvements in that area in due course? Agree it's better than any Casio (not hard!) and along the lines of the nSpire.

Quote:
* [neg] When I throw my 50g in FIX 2, it formats the numbers 123,456,789.00 rather than 123456789.00 on the prime.

The issue here basically boils down to trying to find a way that works universally through the system. The CAS does not support decimal settings nor separators. We want any solution here to be one that works correctly everywhere-not just in the numerical side...


That sounds like an architectural smell to me...

Quote:
* [neg] Took ages to find the boolean operators.

Assuming once you did, the location makes sense? (for those wondering, they are in the popup menu with the less then, not equal and so on on the shift-6)


Yes 100% sensible. I consider this a positive after using it for a couple of hours now!

Quote:
* [neg] * as the product operator is really ugly. I'd expect a dot these days as per the nSpire. To be honest, the output looks like an anti-aliased TI84-series attempt at showing natural/textbook input. Some real polishing needs to be done here.

Again, the issue here comes to trying to combine the CAS and the non-case systems. Bernard's CAS doesn't accept the dot operator, and really is designed for keyboard input text only. A clean solution that doesn't introduce a huge number of unintended consequences has proven very tricky to do.


Architectural smell confirmed. So the CAS works using rudimentary text parsing? I would have thought there as a parser, AST and renderer which was system-wide that the evaluator and CAS could hook into. The CAS wouldn't be concerned about input/output formatting then and would be responsible for manipulating constraints. Sounds like some serious coupling in there. Not saying the 50g was any better here, but it seems odd.

Nice model for constraint evaluation here: http://mitpress.mit.edu/sicp/full-text/sicp/book/node65.html

Quote:
* [neg] STO> doesn't work in RPN mode very well i.e. if you enter 12 'U' on a single line and whack sto, it drops the arrow in rather than executing STO. This is inconsistent with other RPN operators.

The RPN on that early release was not fully complete. It works basically identically now to the 50g with some improvments. For example, you can inline 2d expressions in the input. It also correct recognizes when you are inside an alg region instead of like the 50g where you type 1 '2' 3 and then + will not execute immediately (since you turned on an algebraic at some point earlier).


Fantastic - thanks for the confirmation!

Quote:
* [pos] It has help!

Really good help too! (and much better later once complete) Not sure if that has the ability to search and the examples/related commands at that point.


Either way, it's better than the 50g which I had to source a manual for! I assume programming constructs are nicely documented in this as well?

Quote:
* [neg] Not 100% sure how to see what is assigned in the current scope (as per VAR menu in 50g).

There is no idea of "scope" or folders at this point. Variables created in home or the cas are global. Only limit on scope would be variables created in an application program file. Those would only be visible or active when that app is the currently running one.


That makes sense. Sort of like Casio calcs, which I can live with.

Quote:
* [pos] TVM/Amortization rocks - well done :)

Yeah, that is quite nice (pretty much directly pulled over from the 39gII). Would like to be able to do a lot more in the finance app at some time. Lots more good stuff could be done there with cash flows and similar.


After consulting with colleagues (I'm on the financial side of things), basic stock/bond functions such as P/E ratio, YTM etc would be a big seller. These can be programmed worst case though.

Quote:
* [neg] Few CAS bugs as discussed in other places on this thread.

There have only actually been 5 bugs of any kind discovered on any forums I've been watching (the list2mat thing, a few integrals from a Chinese forum that behaved badly). All are now resolved. The main (loudest?) complaint is the one regarding "does the cas auto-simplify or not?" is not a bug but really a difference of opinion - and of course that issue is being looked at heavily.


I rather like automatic simplification as I'm a business end/professional user and care not for the mechanism but the result. However I can imagine it would be better for education customers to not do this. Flag?

One final thing. Emulator crash:

* Press Help, Select keys from the soft menu, press "a b/c". Boom.

And another edit:

I've ported 11 of my 32 programs to the Prime. No problems so far. In fact, I admit that it's a load easier than RPL. I haven't had to hit any documentation at all so far. I would rather like a "forms entry" type system like the 48-series which can act as a front end for programs though. There might be one but I haven't found it yet!


Edited: 21 July 2013, 6:21 a.m.


>I would rather like a "forms entry"

INPUT allows either a single variable, or multiple. However, it doesn't allow specifying exact box positon/size ala sysrpl at this point.

TW


It would be fine for a futur release ...

something like INFORM on the 50g (or better of course;)


The dialog boxes of TI92/89/v200, are not unsurpassed in the current calculators

I develop a super library of dialog boxes in user-RPL HP48/49/50

http://www.hpcalc.org/details.php?id=7282

espero se inspiren es este trabajo he incorporen comandos especializados en I/O y no se que con simples cajas de dialogo

Jaime


http://www.jaimeza.org/


Edited: 21 July 2013, 11:38 p.m.

Another serious bug in the HP-Prime emulator:

There are lots of functions (in the different Catalogs) for which there's no help available, and if you click on the [Help] button when one of these functions is marked, the emulator crashes: "The application has crashed and will be restarted".

I've tried it e.g. with [Toolbox][CAS][Solve][ODE Solve] and then clicking on the [Help] button, but this happens with tons of other entries, too.

If there's no help available for any function then it should at least give an appropriate message, but not crash of course.

Franz

Edited: 21 July 2013, 6:20 a.m.

Not sure if this is a bug, I admit I haven't read the whole manual yet.
If you enter a program in memory, you can access the list of programs by pushing the "Program" key, and then you see a list of all the programs in memory.
From there you can edit or run a program.
If I edit one, then I can see no easy way to run it, or to go back to the programs list - if I push ESC it goes all the way back to "home".
I know I can press "Program" again, but:

1) I think it'd be nice it pressing ESC brought you back one page (to the programs list), and then pressing ESC again to go to the "home";

2) when editing the program, there is an unused button; I'd like to have "RUN" there, so that I can run the program I just edited without having to take "detours"...


+1 agree with this. A run soft menu entry would be rather useful whilst editing.

yes, I also agree with this improvement.

Quote:
1) I think it'd be nice it pressing ESC brought you back one page (to the programs list), and then pressing ESC again to go to the "home";

I just press "Shift Program" again for this.
To go Home, just HOME

Quote:
2) when editing the program, there is an unused button; I'd like to have "RUN" there, so that I can run the program I just edited without having to take "detours"...

I agree. [Run] could do "Check and Run"


Another error

mat2list([ [ 1, 2, 3 ], [ a, b, c ]]) return [1,2,3,a,b,c] // =( // Matrx to List
mat2list([ [ 1, 2, 3 ], [ a, b, c ]]) return { 1,2,3,a,b,c } // OK

// Request
[HP50] AXL([ [ 1, 2, 3 ], [ a, b, c ]]) return { {1,2,3},{a,b,c} }

Best

mat2list([ [ 1, 2, 3 ], [ a, b, c ]], [#] ) # == get row

mat2list([ [ 1, 2, 3 ], [ a, b, c ]], -1 ) [Enter] or mat2list([ [ 1, 2, 3 ], [ a, b, c ]] ) return {1,2,3 a,b,c } // -1 == list

list2mat(ans,3) return [ [ 1, 2, 3 ], [ a, b, c ]] or // 3 = cols

list2mat(ans,{2,3}) return [ [ 1, 2, 3 ], [ a, b, c ]] // { 2,3} // (rows,cols)

mat2list([ [ 1, 2, 3 ], [ a, b, c ]], 0 ) [Enter] return { {1,2,3},{a,b,c} } // 0 == All

list2mat(ans) == list2mat( { {1,2,3},{a,b,c} } ) [Enter] return [ [ 1, 2, 3 ], [ a, b, c ]]

mat2list([ [ 1, 2, 3 ], [ a, b, c ]], 1 ) [Enter] return { 1, 2, 3 } // 1 row

mat2list([ [ 1, 2, 3 ], [ a, b, c ]], 2 ) [Enter] return { a, b, c } // 2 row

Please rename 2 -> to

mat2List -> matToList


list2mat ->listToMat


Edited: 23 July 2013, 2:31 p.m.


Bug#

more info in spanish

http://www.adictoshp.org/topic/350-emulator-review-hp-prime-virtual-calculator-on-pc/page-4#entry2192


You keep ignoring that any command in the CAS can take any number of arguments.

There is no bug there.

TW

Edited: 23 July 2013, 5:22 p.m.


Quote:
You keep ignoring that any command in the CAS can take any number of arguments.

There is no bug there.

TW


sorry for my bad English =(

any number of arguments OR invalid argument, it should return an error message or not?

[HP-Prime] concat( [[ 1,2],[a,b]], [[3,c]]) [Enter] return [[ 1,2],[a,b] 3, c ] // Bug

[[1,2],[a,b] 3, c ] is a matrix? NO

The CAS (Computer Algebra System) should check if it is a column or row vector valid, for concat command

concat( [[ 1,2],[a,b]], [[3,c]]) [Enter]should return "Error; Invalid dimension second argument"

not only to say that there is error in the dimension, but it detects that argument has problem


Edited: 24 July 2013, 10:09 p.m. after one or more responses were posted


For the fun of it:

Wolfram Alpha says "Hello"!

The result somehow seems to back TW.


Quote:
The result somehow seems to back TW.

No, if take a string as an identifier/variable is valid, but on the HP-prime

"hello" /=/ 'hello'

http://www.unirioja.es/cu/jvarona/downloads/chapuzas.pdf

Note that according to the previous document (chapuzas.pdf), mathematica has bugs

Now wolframalpha: "Hello" == 'Hello' /=/ Hello

With 'Hello' as identifier

with Hello Wolfram Alpha doesn't understand your query

xCAS on PC // ok // "hello" == "hola" in spanish

Edited: 24 July 2013, 9:51 p.m.

Quote:
The result somehow seems to back TW.

It doesn't work with Hello World though.


Possibly Related Threads…
Thread Author Replies Views Last Post
  [HP Prime] "Error while checking exact value with approximate value, returning both!" Chris Pem10 13 5,139 12-06-2013, 05:12 AM
Last Post: parisse
  MS advert shows spreadsheet with obvious error BruceH 3 2,214 11-14-2013, 09:50 AM
Last Post: Bill (Smithville, NJ)
  HP Prime: Rounding error in determinant Stephan Matthys 3 1,685 10-25-2013, 09:29 PM
Last Post: Walter B
  HP Prime Error: Summation Upper Bound > 1000 HP Pioneer 2 1,410 10-25-2013, 11:32 AM
Last Post: steindid
  Prime Error or Mine? toml_12953 12 3,749 10-22-2013, 10:35 AM
Last Post: toml_12953
  Explaination on How to Reset Caculator in Users guie: error Harold A Climer 5 2,608 10-15-2013, 02:11 AM
Last Post: cyrille de Brébisson
  Repair of HP-34C - Error 0 and Error 9 Jeff Kearns 3 1,730 10-11-2013, 12:29 PM
Last Post: Randy
  Do You Think a Listing Error Was Made? Jim Johnson 13 3,963 09-04-2013, 09:23 AM
Last Post: Eddie W. Shore
  PARTFRAC error. Romeu Medeiros 2 1,359 06-23-2013, 10:27 PM
Last Post: Romeu Medeiros
  WP-34s Documentation error Marcel Samek 9 2,862 06-13-2013, 10:25 AM
Last Post: Miguel Toro

Forum Jump: