HP Forums

Full Version: [HP-Prime xcas] operations with complex numbers + BUGs + Request
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Hello

image review:

Review in spanish

http://www.adictoshp.org/topic/423


Edited: 8 Sept 2013, 5:31 p.m. after one or more responses were posted

Hello there.

In light of all these bugs, I wonder how attentive HP is being to fixing these numerous CAS errors this MoHPC group (as well as other beta testers) are finding.

I too am hoping to see the Prime when it's available but, with so many glitches, I hope HP is dedicated to clearing things up.

The vast majority of these posts exhibit few real bugs. For example, in this one he is trying to use settings that apply to the home numerical environment and expecting them to cross over into the cas environment. While an expected behavior perhaps to this user, it is a wrong expectation and the manual clearly documents that it is not correct at the moment. Since the Spanish translated manuals, or even ANY emulator or documents, have not yet been publically released by HP this is not his fault.

Also, his desire for a much stricter input checking, autosimplification by default, and other personal expectations are all flags as "bugs" in this and other posts. Another example here were a whole series of "bugs" related to whether the left or right term was being conjugated.

There are misunderstandings about the product operation, different expectations, and yes, even some bugs. The real bugs are logged for examination and triage. The other things are noted as either things needing re-examination of the behavior to determine if it needs changing, noted as expected behaviors, or as things needing clarification in the (as yet) unreleased documentation.

When the user gives invalid or incorrectly formatted input, and the device returns something unexpected, how is that classified? If they give valid input, but it represents something different then what they imagine it represents and the result is different, how is that classified?

TW

PS - the real beta testers who've had the product for a long time by and large are very happy with the quality of the product and the product itself. Is it perfect? Of course not. Using exclusively this users posts to judge though...


Edited: 8 Sept 2013, 4:50 p.m.

One problem is that Compsytem calls 'bugs' many things that are not 'bugs' in my opinion.

For example display .5 instead of 0.5

or 0.5 wich is interpreted as 1/2 in exact mode on TI wich seems curious to me. I'm curious if the TI replace .333333333333 with 1/3 for example in exact mode wich is not logic in my opinion.

However I agree that the polar_coordinate command is strange at least. It returns a kind of list of 2 elements when you expect a polar representation of the object. You get the lentgh and the angle between [] but can't do any calculation with this.

And <\ key works fine in 'home' but not in CAS (rev 5106)

By the way I don't know in 'home' how to toggle rect to polar display ?

For ex in degree

(100<\45)-> (70.71 ,70.71) or the contrary

(0,0) + (100<\45) does the job but not easy nor beautifull

Hello, sorry for my bad English

A informatic "bug" is very general =(, use best expressions as requirement, improvement, optimization =) OK ...

...
for example, if there is a flag that says TEXT BOOK, then all should work as pretty print: history, entry line, program editor etc

piecewise template put pretty print on entry line, but them from history to entry line is displayed as a line of text =(, improve this in the next version =)

.5 from history to entry line is displayed as 0.5, then why not also put as 0.5 within the history?

1/3 = 0.3333....
http://www.wolframalpha.com/input/?i=1%2F3

Quote:
However I agree that the polar_coordinate command is strange at least. It returns a kind of list of 2 elements when you expect a polar representation of the object. You get the lentgh and the angle between [] but can't do any calculation with this.

completely agree

a function is useful when I can operate on it, a [#, #] does not say anything, is a list?, a vector?, a array?, a matrix?, a poly?, a set? ...?, while [#, <_#] is a vector in cylindrical coordinates or a complex number in polar form =)

I know the answer history within the polar form, but a program can not determine, CAS has no intelligence like ours

I have to create new functions to resolve the ambiguity of the current version of CAS, redo the sum, mult, div, etc of complex numbers

the solution for BUG is simply incorporating a prefix to the second element of the container, it is difficult to do this? [#, <_#]

///

one of the feature that like much in the series HP48, was handling complex numbers in polar form

///

(1,1) + (3+4*i) => 4+5*i

(1.1) is ugly, but more easily operable

//

TIM

Quote:
When the user gives invalid or incorrectly formatted input, and the device returns something unexpected, how is that classified? If they give valid input, but it represents something different then what they imagine it represents and the result is different, how is that classified?

IS CLASSIFIED AS THE CAS DOES NOT DETECT validity ARGUMENT IMPLIES THAT THE USER IS EXPERT IN HANDLING THE CALCULATOR

If you interpret the following expression as polynomial

[ 1, 2 ] + [ 3, 4, 5, 6 ]

The CAS return

[ 4, 6, 5, 6 ]

is that correct? NO, then use a single object container [ ] creates ambiguity

What did the author of xcas to eliminate ambiguity was put a prefix to container poly1[] // OK =)

poly1[ 1, 2 ] + poly1[ 3, 4, 5, 6 ]

The CAS return

poly[ 3, 4, 6, 8 ] // OK

also must do to list, vectors and matrices, are agree or not?

list[ 1, 2 ] + list[ 3, 4, 5, 6 ]

The CAS return

[ 4, 6, 5, 6 ] // OK can be set with zeros (right) valid

but

vec[ 1, 2 ] + vec[ 3, 4, 5, 6 ]

The good CAS return

"invalid dim"

mat[[ 1, 2 ]] + mat[[ 3, 4, 5, 6 ]]

The good CAS return

"invalid dim"

///

The HP-Prime for differentiating sets incorporates prefixes set to container []

set[a,a,EE,o,u,i,a] return [ a, e, i, o, u ] eliminates repetitions // OK

what happens if you do not put the prefix set[]

[a,a,EE,o,u,i,a] return [a,a,EE,o,u,i,a]

many have reported BUGs that are solved by adding a prefix to vectors and matrices

Edited: 9 Sept 2013, 7:18 a.m. after one or more responses were posted

Thanks for this clarification and explanation. The production, testing and product release process makes more sense now.

happy no means satisfied, I am also happy with the emulator of HP-Prime


Edited: 8 Sept 2013, 7:19 p.m.

Others


I hope your comments


Thanks

I have full faith in HP's quality and Tim Wessman. Let's face it; HP needs to get its cash flow started - it can't be cheap to design and produce the Premium units. The HP 25, 67, and 41 etc. and their manuals got my careers started in science and business and I can't wait to get my hands on the new Premiums. If HP/we wait until every possible perceived error has been fixed then we will never get moving. And with (as I understand) the availability of on-line firmware updates I'm ready to buy multiple units for myself, family, and business partners right now.

Thanks Tim for your participation here in the Forum.


Edited: 9 Sept 2013, 10:28 p.m.