![]() |
HP-Prime: issues in entering expressions - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: HP-Prime: issues in entering expressions (/thread-251580.html) |
HP-Prime: issues in entering expressions - fhub - 09-28-2013 Here are a few examples how the HP-Prime reacts on different inputs - Entry: Prime result:Build your own opinion about this strange (inconsistent and unpredictable) interpretation of simple expressions entered in different ways! That's definitely enough for me to stay with my good old (reliable!) TI-92+ ... ;-) Franz
Edited: 28 Sept 2013, 8:57 a.m.
Re: HP-Prime: issues in entering expressions - Gilles Carpentier - 09-28-2013 Hi, just my opinion but all these : (2)x (2)3 (2)(x)^3 1/2(x+3)^4 means absolutly nothing for me
Edited: 28 Sept 2013, 9:01 a.m.
Re: HP-Prime: issues in entering expressions - fhub - 09-28-2013 Quote:Well, whether they mean anything for YOU or not - they are all valid math expressions (provided that we accept the so-called 'implicit multiplication)!
Franz
Re: HP-Prime: issues in entering expressions - David Hayden - 09-28-2013 It appears that trying to handle "do what I mean, not what I say" has introduced a bunch of new errors. In my opinion, it's better to state some simple rules and let the user deal with incorrect input than to make some really complicated rules and let the user deal with incorrect input. If the rules are simple then the user will have some confidence that they have input the right thing.
With that said, I do see one change to "normal" precedence that might make sense: In an expression like a/2b, the implicit multiplication might take precedence over normal multiplication. So a/2b is a/(2*b) but a/2*b is (a/2)*b.
Re: HP-Prime: issues in entering expressions - Gilles Carpentier - 09-28-2013 As I said , it's just my opinion and _I_ prefer to use explicit multiplication All of this is ambigous for me. For example : 1/y(x+3)^4 xy a/bc etc.
Edited: 28 Sept 2013, 9:20 a.m. after one or more responses were posted
Re: HP-Prime: issues in entering expressions - fhub - 09-28-2013 Quote:Well, we had exactly this discussion a few weeks (months?) ago, and I really don't like this 'extra' rule of implicit multiplication - BUT:
It's absolutely unacceptable that an implicit multiplication takes even precedence over exponentiation in the HP-Prime as in my last example: 1That's definitely mathematically wrong!
Franz
Re: HP-Prime: issues in entering expressions - fhub - 09-28-2013 Quote:Yes, your examples are correct because usually we allow multi-character variable-names, and write functions as f(...). But certainly nobody would interpret 2(...) as any function.
Franz
Re: HP-Prime: issues in entering expressions - Gilles Carpentier - 09-28-2013 But it's a strange idea to write someting like (2)X By the way it works in HOME view (2)X -> (2)*X (X)5X -> (X)*5*X
(X)(Y)XY -> (X)*(Y)*X*Y if XY doesn't exist I hope that the difference of behavior between HOME and CAS will be reduce in the future. In my opinion ( ;) ) this is more annoying
Edited: 28 Sept 2013, 9:29 a.m.
Re: HP-Prime: issues in entering expressions - Gilles Carpentier - 09-28-2013 In HOME you get the expected result I prefer to use unambigous 2D (texbook) entry but I agree the CAS behavior is curious here...
XCAS has the same behavior.
Re: HP-Prime: issues in entering expressions - fhub - 09-28-2013 Quote:Yes, the main problem is indeed the CAS, and not only wrt. this entry issues. HP should better have licensed the CAS Derive from TI and used it in their new HP-Prime, instead of XCAS which is (in my opinion) a private hobby CAS where many things are handled completely different to all other professional CAS programs. That's the reason why even a user like me (experienced with almost every existing CAS) has big problems to do the simplest things without looking into the manual.
Franz
Re: HP-Prime: issues in entering expressions - Chris Tvergard - 09-29-2013 You guys have me totally confused by now. I checked Wikipedia for "Order of operations math" and it seems that calculator producers change the rules even between their own editions; there is surprisingly no firm universally accepted norm. I have always believed in explicitly and laboriously entering my expressions with full use of parentheses which the calculator then resolves correctly always, as far as I know. Now, explicit entry seems to be the only responsible thing to do upon reading this Wikipedia article and this Forum. So what doctrine exactly does the Prime stipulate? Are you guys implying it has more than one? Home vs. CAS? Some say that it works in Home, but how can you assume that your Home view conveniently is the (yet-to-be ) established norm? Chris
Edited: 29 Sept 2013, 1:19 a.m.
Re: HP-Prime: issues in entering expressions - parisse - 09-29-2013 Implicit multiplication is accepted only in the following situation: a number followed by a symbol, or a number followed by a symbol to a power, i.e. you can use implicit multiplication for 2x or 3x^2, and that's all. If implicit multiplication is recognized, then no precedence rule apply, i.e. the number times the symbol is considered like if inside parentheses. Therefore 1/2x is parsed like 1/(2*x). Re: HP-Prime: issues in entering expressions - Chris Tvergard - 09-29-2013 Parisse, Many thanks for the heads up. My Prime is a fantastic learning tool and I am discovering new things all the time. Like if one puts a negative sign in front of the base; and unexpectedly to me with parentheses the exponents starts operating on each other and give a huge net result. Like: -2^(2^(2^2)) gives -65536 while (((-2)exp2)exp2)exp2 gives +256. I wish I could send you a screen shot. But in essence I do -2 to the two to the 2 to the 2 without parentheses in the first case, and with parentheses in the second case. I am sure the Prime is correct but it certainly was a surprise to me. And here I thought parentheses always protected me. Bummer. My Prime is doing exactly what I expected: teach me new stuff! Chris
Re: HP-Prime: issues in entering expressions - Han - 09-29-2013 Here is what's wrong with allowing implicit multiplication: 1. Create a program with the following code:
EXPORT NEWT() 2. Enter in 'X^3-8' into F1. 3. Run the program and then check F0 in Symb view. The code above should have worked -- but it doesn't because diff does not return the result with an unnecessary extra set of parentheses. In order to properly form F0, one has to do:
EXPORT NEWT() The trailing +")" can be left off if we want to do some lazy coding. The benefit of now being able to leave off ()'s in 1 or 2 minor cases does not warrant leaving many users frustrated that they are getting "unexpected" results when pretty much every other similar system DOES NOT allow this sort of implicit multiplication. In fact, it flies in the face of the order of operations. Based on Also, from a pedagogical point of view, we are NOT helping students AT ALL by enabling them to lazily type 1/2x and get 1/(2x). If the HP Prime is really supposed to help students learn mathematics, then this minor "feature" is actually a step backward insofar as helping them learn order of operations. I can appreciate that Xcas may be faster than commercial alternatives. However, if it means that users are going to have to always keep an extra set of manuals lying around because it's the one system that does not behave anything like the other ones, I would wager many would simply forgo using Xcas. Because let's face it -- even if Maple were slower, it's cheaper to buy a faster machine and run a familiar piece of software than to spend that extra time having to learn the idiosyncrasies of a competing software. The time saved by faster computations is completely nullified by the time it takes to learn the nuances of Xcas. One need only look at how poorly the RPN graphing calcs have done in the US classrooms. I wholeheartedly believe that the HP50G is still the best calc -- but you won't win over the education market in the US by forcing RPN down everyone's throats. Even more telling is the fact that the HP Prime has put RPN as a secondary option ever since the HP 50G. My point is, Xcas may be superior in many ways -- but unless it is as easy to use as the current commercial offerings with little to no learning curve, it will always play catch up in terms of market share. Lastly, I also find it hard to believe that students in high school or even college would require calculations such that the speed difference given by using Xcas on a calculator would even be noticeable. Most of the problems they will ever face in a class tend to be easily handled by basic programming. If speed were ever really a factor, then even if they used Xcas it would be done on a much more powerful computer and not a handheld.
Edited: 29 Sept 2013, 10:20 p.m.
Re: HP-Prime: issues in entering expressions - parisse - 09-30-2013 Han, I'm not sure I understand all you said.
Regarding the software choice, I agree that ease of use is very important. When I spoke of speed, it was in response to fhub who believes Xcas is just a hobby software. But ease of use is not something intrinsic, it depends on previous knowledge of people, and for a CAS, on math teacher knowledge. Re: HP-Prime: issues in entering expressions - fhub - 09-30-2013 Quote:Well, I can't say anything about C/C++ or yacc because that's not my programming language, but I can tell you my opinion about 'implicit multiplication' and how it should be handled. First, implicit multiplication is ok if it's ONLY an abbreviation for a missing (or omitted) multiplication char (*), but it should definitely NOT change the usual precedence rules at all. That means if the parser discovers such an implicit multiplication, then it should simply insert a * character into the expression, but nothing else, i.e. no extra (...) at all.
Example: the parser should replace 1/2x by 1/2*x, BUT NOT by 1/(2*x) because this is a violation of the precedence rules.
Ok, so far about implicit multiplication in principle - and now about WHERE or WHEN such an implicit multiplication should be allowed:
A variable followed by a left round bracket - for example x(expr) - can't be treated as implicit multiplication, because that's usually a function call. So only the 4 situations above make sense to interpret them as implicit multiplication. Franz
Re: HP-Prime: issues in entering expressions - parisse - 09-30-2013 I consider myself that 1/2x should not be used because it's ambiguous. Re: HP-Prime: issues in entering expressions - Gerson W. Barbosa - 09-30-2013 Quote: Ambiguity is too high a price to pay for this, IMHO. WolframAlpha/Mathematica make a distinction between 1/2x and 1/(2x). If this cannot be done on the Prime, it is better to have implicit multiplication disabled. This is just my opinion, though.
Edited: 30 Sept 2013, 10:48 a.m.
Re: HP-Prime: issues in entering expressions - Han - 09-30-2013 Quote: I agree -- disable it until it gets worked out. Disabling on the HP Prime will help reinforce the order of operations. There are really only two outcomes: 1. If implicit mult. is disabled: The students who don't have the order of operations mastered (or occasionally forget to account for them) will now have to explicitly multiply. They might not like it, but at least they will be given reinforcement that these rules matter -- and for those who forget, they will be more likely to appreciate the reminder. I remind my students when they use their TI calculators and they always smile at themselves while saying "oh yeah..." or "aha!" Edit: Given that there is also textbook entry now, this group of users would likely never go back to algebraic entry anyway. 2. If implicit mult. is left as it currently is: The students and teachers who DO recognize the order of operations will undoubtedly find this not only annoying, but also consider this "feature" a bug. Regardless of the documentation and the ease of input, the "feature" is a complete contradiction of what has become mathematically and universally accepted (referring to order of operations). And those who do not have this concept mastered -- all it does is now further enable them to think that it's "ok."
Edited: 30 Sept 2013, 12:02 p.m.
Re: HP-Prime: issues in entering expressions - Han - 09-30-2013 Quote: (2)X is not strange. In fact, it comes up often in calculus for students who first learn about shortcuts to computing derivatives. When first learning the derivative rules, all the explicit steps are often shown until students become comfortable enough to do some of the simplification in their head. But leaving in the intermediate steps helps them visualize the application of a particular derivative rule (or several). f(x) = e^(2x)*x ===> f'(x) = e^(2x-1)(2-0)*x + e^(2x)*1
As for (X)(Y)XY -- this should always mean X*Y*XY if the system is going to allow for variables of several letters. On the lower-end TI-84 models in which only single-letter variables are allowed, then the implicit multiplication would make sense (that is, XY means X*Y). However, XY must always be treated as a single variable on systems which accept more-than-one-letter names. Otherwise, having XY interpreted as possibly X*Y or XY depending on the existence of a variable 'XY' is just asking for a lot of headache.
Re: HP-Prime: issues in entering expressions - fhub - 09-30-2013 Quote:Well, did you write your XCAS for mathematical idiots or for people with (at least a minimum of) mathematical knowledge? ;-) Quote:I already explained how it could/should be implemented: whenever you encounter an implicit multiplication, simply insert a * in the expression at this place, but DO NOT add any extra () around these 2 factors.
Franz
Re: HP-Prime: issues in entering expressions - parisse - 09-30-2013 Interesting, fhub, we do not have the same definition of implementation : I meant of course writing source code for bison/yacc that implement precedence rules. Describing precedence rules is easy, writing source code for that is another matter. Re: HP-Prime: issues in entering expressions - Han - 09-30-2013 Perhaps the following compromise would be better: Introduce a flag / setting in which implicit multiplication is enabled or disabled and let the users decide. I would not even mind if the default setting was enabled.
The reality is that since we have textbook entry, most users will probably use that mode instead of algebraic input.
Re: HP-Prime: issues in entering expressions - fhub - 09-30-2013 Quote:I don't really see the need for such an extra flag or setting - even if implicit multiplication is implemented, nobody is forced to use it. And IF anyone enters such an expression as for example 2x, then it's definitely better to automatically (i.e. always) treat it as 2*x, because what would be the alternative? It could only be to give an error message, and that's also not really confortable.
Franz
Re: HP-Prime: issues in entering expressions - Han - 09-30-2013 Quote:
Your hypothetical case in the second paragraph and the fact that some people find 1/2x (as a shortcut for 1/(2x)) useful is precisely why such a flag should be implemented. It is clear from the discussion that there are those who would prefer to have that shortcut. When enabled, then 1/2x gets interpreted as 1/(2x). When disabled, 1/2x becomes (1/2)*x. No error message needs to ever show up.
Re: HP-Prime: issues in entering expressions - fhub - 09-30-2013 Quote:Well, then 95% of all calculators and ALL other serious CAS are 'completly artificial' in their expression parsing??
That's what I meant when I called XCAS a 'private hobby CAS' - it fulfills YOUR wishes/believes and standards but not the usual mathematical conventions.
Franz
Re: HP-Prime: issues in entering expressions - fhub - 09-30-2013 Quote:Ok, I agree with you about such a flag - and this setting should be called: [x] Violate the math rules vs. [ ] Accept the math rules ;-) But even this flag won't help against the wrong XCAS result for 1/2(x+3)^4 ... :-(
Franz
Re: HP-Prime: issues in entering expressions - parisse - 10-01-2013 Quote:maple does not parse 2x, are you considering that maple is not a serious CAS? There is just no mathematical convention for parsing 2x, because it's not math, it's computer-human interface, in math, you write your expression in 2-d. I parse 1/2x as 1/(2*x) not because it's my wish or belief how it should be, I parse it like that because I don't know how to write source code to parse it using precedence rules (it seems you don't know too), I don't think it's important (especially for the HP Prime where the average user will enter expressions in 2-d) and I have much more interesting math algorithms to implement. If this prevents you from using Xcas, it's your problem, I don't care about users like you who dismiss the work of others like you do. Re: HP-Prime: issues in entering expressions - fhub - 10-01-2013 Quote:Not parsing 2x (i.e. not allowing implicit multiplication at all) is ok, but parsing 1/2x as 1/(2*x) instead of 1/2*x is not ok and mathematically wrong - and no serious CAS interprets it this way. Quote:You got me wrong, I don't dismiss your work at all, in fact I even think that XCAS is a great work! All I wanted to say with my previous postings is, that XCAS should just stick more to the usual math/CAS standards, that's all.
Franz
Re: HP-Prime: issues in entering expressions - Han - 10-01-2013 Quote:
Inside a program on the HP Prime this does not seem to work. Do you have an equivalent suggestion for use within a program?
Re: HP-Prime: issues in entering expressions - Tim Wessman - 10-02-2013 You can create a CAS function, and then call that from the "normal" program.
TW
|