Odd bug with 'solve'
04-24-2021, 07:16 PM
Post: #1
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
Odd bug with 'solve'
I've attempted to show it here with a simple example where an equation is being rewritten as 'z='.

When rewriting an equation for a particular variable; everything functions as it should with any variable letter other than 'i'. For 'i', the variable is replaced by (0,1) when 'Entered'.

All a-z variable are clear, other than those being used by the current graphs (it was the first thing I checked).
04-24-2021, 08:13 PM
Post: #2
 toml_12953 Senior Member Posts: 2,144 Joined: Dec 2013
RE: Odd bug with 'solve'
(04-24-2021 07:16 PM)jonmoore Wrote:  I've attempted to show it here with a simple example where an equation is being rewritten as 'z='.

When rewriting an equation for a particular variable; everything functions as it should with any variable letter other than 'i'. For 'i', the variable is replaced by (0,1) when 'Entered'.

All a-z variable are clear, other than those being used by the current graphs (it was the first thing I checked).

i is the complex variable (0,1) 1 being the imaginary part.

Tom L
Cui bono?
04-25-2021, 05:35 AM
Post: #3
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
RE: Odd bug with 'solve'
(04-24-2021 08:13 PM)toml_12953 Wrote:  i is the complex variable (0,1) 1 being the imaginary part.

How stupid of me. I thought that the italicised symbol i was treated differently to a lower case i. I also have my calculator set up to use (a,b) for complex numbers rather than i.
04-25-2021, 06:23 AM
Post: #4
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
RE: Odd bug with 'solve'
I've just doubled checked on the Nspire and the symbol is indeed treated differently than the lower case letter.

This 'bug' probably originates in XCAS starting out life as a desktop product where it's not so easy to differentiate between an italicised lower case letter and the symbol for the imaginary number i.

The Nspire provides the better workflow in this instance, especially considering that the Nspire is primarily used by pre-university students.
04-25-2021, 04:45 PM
Post: #5
 parisse Senior Member Posts: 1,322 Joined: Dec 2013
RE: Odd bug with 'solve'
There is special code in the parser to detect i inside a loop as an index, but inside a solve command or other CAS expressions, i is and will remain sqrt(-1) (unless you activate some compatibility mode, for example inside Xcas xcas_mode(1) will activate maple compatibility where sqrt(-1)==I).
Most calculators and some desktop programs prefer to have a special i letter, but it is hard to get this character on a desktop keyboard and moreover it is not the same unicode char everywhere which means that if you are using a special i you will probably have to stay with the same program/calculator (probably a reason to get calc maker happy!).
I strongly believe it is much better to have a standard letter for sqrt(-1), and I think lowercase i is better than uppercase I (but I leave the choice to the end user). The Xcas lexer accepts the following versions of i, from input_lexer.ll
Code:
 "i"            index_status(yyextra)=1; if (xcas_mode(yyextra) > 0 || !i_sqrt_minus1(yyextra)) { (*yylval)=i__IDNT_e; return T_SYMBOL; } else { (*yylval) = cst_i; return T_LITERAL;}; "ί"                      index_status(yyextra)=1; (*yylval) = cst_i; return T_LITERAL; "?"                     index_status(yyextra)=1; (*yylval) = cst_i; return T_LITERAL; ""                      index_status(yyextra)=1; (*yylval) = cst_i; return T_LITERAL; \xa1                    index_status(yyextra)=1; (*yylval) = cst_i; return T_LITERAL;   /* \xef\xbd\x89            index_status(yyextra)=1; (*yylval) = cst_i; return T_LITERAL; */ \xe2\x81\xb1            index_status(yyextra)=1; (*yylval) = cst_i; return T_LITERAL; "I"                     index_status(yyextra)=1; if (python_compat(yyextra)>=0 && (xcas_mode(yyextra)==0 || xcas_mode(yyextra)==3 || rpn_mode(yyextra)) ) { return find_or_make_symbol(yytext,(*yylval),yyscanner,true,yyextra); } else { (*yylval) = cst_i; return T_LITERAL; }; "%i"            index_status(yyextra)=1; (*yylval) = cst_i; return T_LITERAL;
04-25-2021, 06:58 PM (This post was last modified: 04-25-2021 07:06 PM by jonmoore.)
Post: #6
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
RE: Odd bug with 'solve'
I believe the confusion is compounded by the fact that there's a symbolic 'i' on the calculator keyboard accessed via Shift + 2.

Much as I prefer the HP Prime over the TI Nsprire CX CAS II, I am also of the belief that the Nspire is a superior calculator for pre-university students aged 14-16. Part of the reason I believe that the NSpire is superior for that age group is that over the years TI has done a lot of work to adapt Derive specifically for calculator use. So it has minimal 'lurking' desktop keywords, functions and workflows.

Whilst I applaud and agree with the majority of the design decisions utilised in XCAS/Giac, I think they often muddy the water as part of general use on the HP Prime. If something isn't documented in the extensive Prime PDF manual, it shouldn't exist in the OS. I'm sure it's easier for HP to integrate XCAS as is, but it would be better if it were properly adapted, with no hidden keywords and commands.

This is another of the reasons that I want to access KhiCAS on the HP Prime (and delivered with all the performance benefits of a HP equivalent to 'ndless)'. The XCAS design decisions make total sense in that context.

To digress a little, I've found with our kids that I'm able to use the document modes of the Nspire to provide them with extra Algebra drills to help cement their curriculum. The great thing about the document mode is that they can easily show their 'by hand' methodology whilst checking their work with the CAS.

For our eldest (currently doing A-Levels), and who goes to university next year, it's the HP Prime and an A3 whiteboard all the way. That's a far faster way to help with the higher-level math problems encountered at that age. Having to traverse a document mode here gets in the way.

Funnily enough, I really don't see the Nspire and the Prime as direct competitors much as their perceived that way. But I'm not sure how long HP can continue to create high-end calculators if they're only catering to 'university' students, who in many cases, will be using Matlab, Mathematica, Maple etc on their laptops/tablets. Unfortunately, the pre-university market is governed more by what functionality is left out than that, that's put in, hence the dominance of Casio here in the UK. And I'm not sure HP has always been that successful when creating sub-prime models (the 39 and 40g's are a good example of this).
04-26-2021, 03:18 PM (This post was last modified: 04-26-2021 03:22 PM by Wes Loewer.)
Post: #7
 Wes Loewer Senior Member Posts: 459 Joined: Jan 2014
RE: Odd bug with 'solve'
(04-25-2021 06:58 PM)jonmoore Wrote:  I believe the confusion is compounded by the fact that there's a symbolic 'i' on the calculator keyboard accessed via Shift + 2.

It took me a while of using the Prime before I noticed that there was an i on Shift + 2. I had been using lower-case i. I suppose it is not completely redundant as it provides some consistency in key strokes between Home and CAS. Lower-case i requires a shift in Home but not in CAS.

There is a similar issue with e. On the Npsire, there are 4 different e's: lower-case e, upper-case E, scientific notation E, and the constant e, and they are all distinct. The Prime has three e's but they seem to be at least partially interchangeable.
1.23e4 = 1.23E4 = 1.234E4 = 12300. I got snagged on this once when I tried to calculate something like 2*e^3 but tried to use implied multiplication 2e^3 and got a syntax error that I incorrectly thought was a bug.

Similar issue with the negative character and subtraction character.
04-26-2021, 08:01 PM (This post was last modified: 04-26-2021 08:06 PM by jonmoore.)
Post: #8
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
RE: Odd bug with 'solve'
The consistent thing to do on the Nspire is to always use the symbolic options provided via the dedicated keys and the 4 cascade menus keys. The dedicated alpha keys should strictly be used for entering CAS commands or for variable names\letters.

But this isn't about any particular calculator, it's more about what I consider to be a UX best practice for calculators used for education environments, including CAS models.

A calculator has the ability to differentiate between standard alphanumeric character input and the symbols students encounter in their textbooks. When a qwerty keyboard is used with a desktop computer, dedicated keys aren't the norm, so CAS tool interaction models tend to be used with programming language style UX models; to the extent that the use of dedicated pallets are sneered upon by power users of the likes of Mathematica and Maple. And rightfully so, treating Mathematica and Maple as glorified calculators kind of misses the point.
04-27-2021, 05:14 AM
Post: #9
 cyrille de brébisson Senior Member Posts: 1,047 Joined: Dec 2013
RE: Odd bug with 'solve'
Hello,

Having different, same looking symbols mean different things and non-interchangeable is a PITA for 'regular users'. See how long it too to educate people that a '-' and a '_' were different (for email addresses and the like)...
try telling them that an e an e and an e are different!

Also, since we wanted to be able to use computer keyboards to work, we needed to be able to handle normal characters...

The cas, coming from the PC, did also not have special characters...

All this got together to make the syntax relatively flexible and permissive.

Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
04-27-2021, 06:48 AM (This post was last modified: 04-27-2021 06:49 AM by jonmoore.)
Post: #10
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
RE: Odd bug with 'solve'
Cyrille, I wasn't suggesting that the decisions for the CAS to operate as it does, was without purposeful thought, but I do disagree with the solution. With specific response to your point on 'regular users', I don't buy that at all. Regular users don't purchase a CAS calculator, if they do, point them my way and I'll show them how to save at least €100!

Bad humour aside. The primary market for the Prime and Nspire is education, where teachers & lecturers prioritise the teaching of symbolic math, not computer algebra systems. The fact that a CAS is a useful solution towards answering symbolic math questions is secondary.

The HP Connectivity Kit is not unlike the TI Teacher/Student software but in execution, they are very different. I won't bother going into the details here, but the desktop software allows qwerty input and easy access to specialist math symbols side by side, much like Mathematica and Maple. The fact that the HP Connectivity Kit doesn't, is a weakness to be solved not a reason to treat all input as standard qwerty alphanumeric input.

I'm a huge fan of XCAS/Giac even though I maintain licenses to Mathematica, Maple and Matlab. I use it most often directly in the terminal as I find that more direct than the standard UI tools in said commercial math software (some of these also have command line interaction modes but the relative simplicity of Giac is preferable). But this doesn't mean I want to interact with a calculator in the same manner as I do with Giac (as a primary interaction model). I really enjoy using KhiCAS on the calculator platforms where it's available but this is very much a secondary interaction model.
04-27-2021, 01:29 PM
Post: #11
 parisse Senior Member Posts: 1,322 Joined: Dec 2013
RE: Odd bug with 'solve'
Not sure I understand all you said, because my English is not good enough, so maybe my answer will not correspond to what you say (and it is of course my view, not that of Cyrille).
I believe it is essential to teach students things that will still be true/useful 30 years in the future. For math/CAS/calculators, that means being capable to input a commandline, independently of the UI. 2d input is good but it should not be used as an excuse not to teach how to enter a valid 1d expression with operator precedence and parenthesis (and this is certainly a good thing if you want later to write a program). Commandlines should be easily copied, exchanged and pasted from one software to another one, and that is in favor of using plain ascii text. Menu or keyboard help is nice, but I think it should enter a normal i for sqrt(-1), and not a fancy i. For comparison, I would certainly recommend teaching Unix commands in a terminal to CS students.
This is probably not a view shared by many math teachers. Perhaps it comes from the fact that I'm totally lost with UI that are not text-oriented, like those you find more and more these days (e.g. on smartphones), I simply can not associate a function for most pictures I see unlike with a classical textmenu entry (and obviously most users are built differently than I am).
04-27-2021, 03:02 PM (This post was last modified: 04-27-2021 03:05 PM by jonmoore.)
Post: #12
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
RE: Odd bug with 'solve'
I agree with many of your points, but I grew up with the UNIX terminal so the command line comes naturally. It's what I love about Raspberry Pi's, it brings kids closer to the 'metal' - ie the command line.

It's a real pity that the https://www.computerbasedmath.org/ programme is a shallow attempt by the 'Brothers Wolfram' to sell more Mathematica licences into the education sector, as some of its aims have a lot of merit.

But, and this is really important, learning math shouldn't be something that requires knowledge of computer science. Kids aged 12-14 have enough on their plate moving from arithmetic to the math of symbol manipulation, without having to learn the syntax of Maple/Mathematica/XCAS etc. The reason Maple succeeds with younger students over other CAS alternatives is because of its 2d mathematical interaction model that doesn't require them to learn the underlying Maple syntax. By the time these students are 16 and beyond and when they hopefully have an innate intuition for symbolic math, it's at that point that learning the underlying syntax comes to the fore.

I'll speak plainly here as I think this is really important. It's no secret that HP hasn't been particularly successful in promoting the Prime in the (age) 11-16 education segment. In the UK market, they begin to have some cut-through with the 16-19 segment (mainly IB students), and have reasonable success with university students that still see a calculator as being relevant to their studies.

I'm not from an educational background professionally, but I owned a design agency specialising in digital media and ended up doing lots of production work for the education sector over the years. I sold the agency to a larger network in 2008 and work mainly as a consultant these days. And some of that work remains in the education sector. The general view on the HP Prime with my education sector clients is that it's fantastic hardware let down by an operating system that's not fit for their purposes.

Back when HP were marketing the HP-50g against the TI-89 (and earlier CAS models), the 50g was the clear winner with both end-users and educators. The same hasn't been the case with the HP Prime. Here in the UK, the biggest reseller of calculators to the education sector is Oxford Educational. Their summer 2021 catalogue (which I've linked to below) doesn't even feature the HP Prime (even though they stock it). It leads with the Casio Classwiz calculators, then the Casio CG50 and its low-cost mono twin (the fx-9860G-III), and finally, at the back of an 18-page catalogue, comes the TI calculators. But even here it's only the TI-Nspire CX II-T that's listed alongside the TI-84 Plus and the TI-84 Plus CE-T Python Edition. Educationalists here in the UK neither recommend CAS calculators to their students nor do they purchase them in bulk. I personally think this is a narrow minded approach but that's the truth of the situation. I don't know the mainland European education sector as well as the UK sector, but I've been informed that the situation is mirrored in many countries.

When TI started using a Mathematica like notebook interaction model on their calculators, it was underpowered and cumbersome but technology has caught up with their initial vision and the CX II is just as responsive as the Prime. Going forward I seriously think that HP should consider a document model for any possible Prime replacement (but one that can be easily disabled by those who don't need it). Hopefully, attitudes will have advanced enough that that won't have to offer a CAS free model. But by marketing a calculator that can successfully be seen as a good solution for students aged 11-19 and beyond, we all gain; as HP will hopefully still be in the business of selling calculators.

https://www.studentcalculators.co.uk/pdf...20Full.pdf
04-27-2021, 04:09 PM
Post: #13
 Albert Chan Senior Member Posts: 2,682 Joined: Jul 2018
RE: Odd bug with 'solve'
(04-25-2021 06:23 AM)jonmoore Wrote:  I've just doubled checked on the Nspire and the symbol is indeed treated differently than the lower case letter.

I am not a fan of multiple values for i and i (or, is it i vs i ?)
Which is the real i (√-1) ? Both look italicized to me !

Perhaps my i is getting old
04-27-2021, 04:40 PM
Post: #14
 ijabbott Senior Member Posts: 1,305 Joined: Jul 2015
RE: Odd bug with 'solve'
(04-27-2021 04:09 PM)Albert Chan Wrote:
(04-25-2021 06:23 AM)jonmoore Wrote:  I've just doubled checked on the Nspire and the symbol is indeed treated differently than the lower case letter.

I am not a fan of multiple values for i and i (or, is it i vs i ?)
Which is the real i (√-1) ? Both look italicized to me !

The bold one is the real (or rather the imaginary) i.

— Ian Abbott
04-27-2021, 06:25 PM
Post: #15
 parisse Senior Member Posts: 1,322 Joined: Dec 2013
RE: Odd bug with 'solve'
@jonmoore: apart from Mathematica that has its own strange native syntax, learning one CAS syntax will be useful for all other CAS. It's fairly easy to adapt from Xcas/HP Prime CAS to Maxima, Maple, or Derive/TI92/Nspire. I do not consider that learning how to enter a valid commandline in a CAS is computer science, I strongly believe it is part of maths. Entering a 1d commandline will help understand the priority rules of operations and this is fundamental to understand math notation. Writing explicit multiplication will help some students understand some implicit rules.
2d input or "rich" interfaces will perhaps ease the initial use, but it will make the learning curve harder, and it will make the tool much more a blackbox, and that's bad.

As for calculators: I don't know for other countries, but here in France, the Prime is too expensive for most highschool students. Only those who know that they will learn advanced math/science after highschool might buy a calc with a price > 100 euros. The vast majority of highschool students buy a 50 to 80 euros calculator, and that's the reason why I ported KhiCAS to the Casio and Numworks, despite the fact that these platforms have very limited RAM available.

I know that many math teachers do not share my view on teaching math with calculators. My opinion is that a calculator should not be like a textbook designed for a course, with some apps designed for some courses, and when the curriculum changes then you must change the calculator (or the manufacturer must provide new apps, but of course manufacturers prefer to sell a new device): that's exactly what happened when someone here decided that Python was the only language for programming in French highschool.
I believe that a student should learn a little bit how to use a calculator, which means how to enter a commandline and find help on commands [and not which fields you must fill in an app] and then be able to solve one particular problem himself. And for those that like it, the calculator should help them discover things that are not in the curriculum, in maths and also by providing a diversity of programming languages and leave the user decide which one he likes more.
04-28-2021, 08:22 AM
Post: #16
 jonmoore Senior Member Posts: 309 Joined: Apr 2020
RE: Odd bug with 'solve'
(04-27-2021 06:25 PM)parisse Wrote:  I do not consider that learning how to enter a valid commandline in a CAS is computer science, I strongly believe it is part of maths.

I suppose this is at the crux of where we disagree. Elements of computer science are a great example of applied mathematics, but other than that, a computer is purely an enabler for solving and exploring mathematical problems.

Don't get me wrong. All of our kids were introduced to the command line and simple computer programming before the age of 11. Nonetheless, I think it's important that kids learn symbolic math manipulation, free of computers and calculators. In truth, if those kids end up studying math/science post 18/19 and entering careers using those mathematical skills, computers will be at the heart of their work. However, learning symbolic manipulations by hand teaches lateral thinking and problem solving and that's invaluable.

I don't see myself as being aligned to fusty old math teachers, and on that basis as mentioned earlier, I maintain licenses to Mathematica, Maple, and Matlab, and all our kids no matter their age have access to CAS calculators be they hardware or iOS. But I do attempt to get them to use the technology they have access to, for the exploration of mathematics, rather than seeing said technology as a quicker way to finish their homework problems!

I've always found that reverse engineering a knowledge domain is a fantastic way to solidify learning, so I'm happy if our kids first solve a problem with a CAS as long as they document the steps of solving the problem by hand (any attempts to use a computer-generated step by step answer are often easily spotted). In many ways, reverse engineering a problem from the answer is a more powerful way of enabling retention and I've found with our kids, it's a challenge they relish in ways they often don't when faced with a problem and a blank piece of paper.
04-28-2021, 12:40 PM
Post: #17
 parisse Senior Member Posts: 1,322 Joined: Dec 2013
RE: Odd bug with 'solve'
(04-28-2021 08:22 AM)jonmoore Wrote:  Nonetheless, I think it's important that kids learn symbolic math manipulation, free of computers and calculators.

Perhaps I was not clear enough. I believe that math learning process must involve a computer/calculator-free part, this should be mandatory for examples that can be solved mentally (which probably means all symbolic manipulations before the age of 15). But for computations requiring paper and pencil, this computer-free part should be limited to simple examples that help understand a math concept.

For more technical computations, the human brain is just not adapted. Of course, it is possible to train some people to be excellent at computations, and in fact there were paid jobs for that before about 1960. Some kids might even like that (kind of a sportive competition). But I don't see any valid reason to force those who don't like that, since CAS are available everywhere (on a smartphone for example). Instead we should teach kids how to verify and/or solve technical computations with a CAS, in a way that will be useful with any CAS software (that's the reason why I think we must teach commandline 1-d input), and I strongly believe that this teaching should be done in the math class and not in computer science.
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)