• 0 Vote(s) - 0 Average
• 1
• 2
• 3
• 4
• 5
 Still Bugs in New firmware 2016 04 14 (10077)
25-04-2016, 06:16 PM
Post: #1
 t2d234 Junior Member Posts: 2 Joined: Apr 2016 Reputation: 0
Still Bugs in New firmware 2016 04 14 (10077)
Hi,
I tested the new firmware. Some Bugs have been eleminated, others are still there.
For example the linear solver does not calculate the correct results.
You can see this in the first attached picture. The result should be the same on both calculators as there is only a swap of colomn 1 and colomn 3.

Please fix it soon and do not wait again several months.
Thanks.

You can see another annoying bug in picture 2.

Please don't tell me to use the CAS-mode. This is not allowed and disabled in our exams.

Timo
26-04-2016, 07:59 AM
Post: #2
 brebisson Junior Member Posts: 12 Joined: Mar 2016 Reputation: 0
RE: Still Bugs in New firmware 2016 04 14 (10077)
Hello,

I know that it will not help you, but I can at least try to explain the reasons for the answers that you are seeing.

Regarding the linear solver, the problem has no solution as you know (and as the 2nd calculator shows correctly).

The reason why the first calculator does give an answer is because they answer is correct at 11 digit precision.

In order to avoid 'unruly' results in matrices operations (.999999 and very small items where a 0 should be), matrices operations are rounded to 11 digits.
The data in the first example do lead to these large numbers being valid solution at 11 digit accuracy. The 2nd does not lead to it.

Of course, the way to detect such issues is to notice that the results are way out of wack with the inputs.

For the fraction examples, we have a similar, albeit different cause.
When you use the ab/c key, they calculator tries to find the simplest (read smallest possible nominator and denominator) fraction which is equal to the input plus or minus "display order of magniture-1".
Here, display precision is 12, order of magnitude is 11 digits.
1/1e9 - 1/990099010 = -9.999..e12

so, the result returned by the calculator is 'simpler' (within the criteria stated above) than the original input and is the result returned.

Of course, both issues are caused by the user of inexact arithmetic, and the solution for this is, as you know use of exact arithmetic, which means .... but I won't say it because you specifically requested that we do not do so...

So, once again, I am sorry that I can not fit it for you right away, but I hope that these explanations do help.

Regards,
Cyrille
04-05-2016, 08:29 AM (This post was last modified: 04-05-2016 09:06 AM by t2d234.)
Post: #3
 t2d234 Junior Member Posts: 2 Joined: Apr 2016 Reputation: 0
RE: Still Bugs in New firmware 2016 04 14 (10077)
Hello,
I know that your are right, but as you said it will not help me.
I don't know any other calculator designed for use at school (i.e. TI or Casio) that isn't able to do that calculations without confusing the pupils.
We introduced the HP Prime two years ago at our school because of many good reasons, but these problems are really knockout criteria for use at school.

Is there anyone from hp reading this? Do you think, everything is OK?

Best regards
Timo

By the way, the RREF-Function is able to calculate the correct solution without using the CAS.
But using the RREF-Function depends on the ability to interact with Matrices.

Attached File(s) Thumbnail(s)

05-05-2016, 08:15 AM
Post: #4
 brebisson Junior Member Posts: 12 Joined: Mar 2016 Reputation: 0
RE: Still Bugs in New firmware 2016 04 14 (10077)
Hello,

I am from HP, but when posting in public forums, "we do not speak for HP". So, anything that I say here only represent my own views and should in no way be viewed as official HP statements.

What I can tell you, because it has been stated many times in the past, is that HP has long taken the point that it will not try to hide the 'reality' of finite precision math from the users. ie, 1/3*3=0.99999... because this is what really happens, and any tentative to hide it results, later on, in other troubles which are much harder to catch.

The math library is (normally) precise to at least 11 significant digits (and in most cases to 1/2 of the 12th significant digit).

I do not think that this is 'normal', nor 'abnormal' for that mater, this is the reality of real life math, and any math user should be educated to these idiosyncrasies, because they will come and bite him later (we all know the excel 100-99.99-0.01 !=0)

Personally I think that the problem stems from what I call "lies to children". We tell children lies (especially during education) to make our (adults) life simpler.
Personally, with my own kid, I strive to never do such things. When something strange/unexpected happen (like 1/3*3=0.9999...) I try to use this as a 'teaching moment', an opportunity to show him how deep and wonderful the world really is. When the answer is too complicated for him, I tell him to go write the question in his book at year 'n'. His book has 5 pages per 'year', and we estimate at what age he will be old enough to understand the answer and write the question there. Then on his birthday, we look at the book on that 'year page' and try to answer the questions!

Of course, this is something that I can do, alone with my own kid, but which is "slightly" harder to do in a classroom setting with 30 kids and a curriculum to follow. But I nevertheless think that it is better to not hide the reality, if anything to let the pupils know that there is more to the world than the simple version which is presented to them.

One reason why I think this is because, in my professional job, I have seen way to many bad software code with things like if a=b (with a and b being reals), or even plain simple integer overflows.

Anyhow, sorry for the digression, returning to RREF, I can not promises anything, but I can put this in the list of things to fix so that at least it is looked at.
As stated above, the problem can not be fixed without going CAS, but it might be partially hidden (ie, made harder to detect/reduce the occurrences) by moving all RREF calculations to 15 digit precision instead of 12.

Regards,
Cyrille
06-05-2016, 07:18 PM
Post: #5
 meeder Junior Member Posts: 5 Joined: Jan 2016 Reputation: 0
RE: Still Bugs in New firmware 2016 04 14 (10077)
(05-05-2016 08:15 AM)brebisson Wrote:  What I can tell you, because it has been stated many times in the past, is that HP has long taken the point that it will not try to hide the 'reality' of finite precision math from the users. ie, 1/3*3=0.99999... because this is what really happens, and any tentative to hide it results, later on, in other troubles which are much harder to catch.

The math library is (normally) precise to at least 11 significant digits (and in most cases to 1/2 of the 12th significant digit).

I can understand the idea that HP has but it does look quite stupid to people who do not know that this behavior is deliberate. A €9 scientific calculator calculates 1/3*3 as being 1. So I totally understand people assuming that a €130 calculator does the same, yes I know assumption is the mother of all f***ups
In CAS mode I assume that it leaves the 1/3 as a fraction in tact and then it does come up with the answer as being 1.
 « Next Oldest | Next Newest »

Forum Jump:

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