HP 35s Checksum explained
02-11-2015, 08:18 PM (This post was last modified: 02-11-2015 08:20 PM by MarkHaysHarris777.)
Post: #21
 MarkHaysHarris777 Senior Member Posts: 333 Joined: Jan 2015
RE: HP 35s Checksum explained
(02-11-2015 06:55 PM)Tugdual Wrote:
(02-11-2015 06:39 PM)Tim Wessman Wrote:  I think you meant to say "enabling unauthorized modification to support cheating in exams"...

(which is how all non engineering types view things unfortunately)

Tim, please don't forget that many people but students use calculators. I really think that a HP design with an open firmware is a new concept that has never been done and would find a public of professional users. I am under the impression that HP is now totally and exclusively focusing on the school market.

hi Tim, Tugdual, nice to meet you... I would also add that it is my opinion that testing (like the NCEES exams) will morph, eventually. The engineering student should not be tested on how well they take a test, nor on the level of sophistication of their calculator. The exam should consist of 500 questions (taken from every discipline) selected at random from 300,000 exam questions over a five hour period. The examine continues until 500 questions are answered in less than five hours; end of story (no one takes the same exam, duh). The student should be allowed three calcs on the desk! They should be allowed reference works (standard on-line) and they ought to be able to bring to the desk (1) sheet of A3 or 8.5 x 11 inch paper with *anything* written on it at all! The exam should test their engineering skills, not their test taking skills. In other words, the exam should be soooo open that it precludes cheating of all kinds, including whether the firmware of the calculator is giving them an advantage.

Having said that... one of the things my son and I discuss is the advantage of bringing an HP calculator to the NCEES exam. NOT TO CHEAT... no. To program that sucker for maximum advantage and flexibility while taking the exam. The HP35s has at least (IMHO) a 10 : 1 advantage over the FX115es Plus or the TI 36x Pro for flexibility and power; if programmed correctly, and if organized efficiently.

The WP34s (at this point) would be even better... although its a mute point since the calc is not permitted by NCEES. I do not believe the WP34s would give any greater opportunity for cheating than any of the calcs allowed right now.

As for the student market, I must agree with Tugdual. Its not just HP either. All of the calculator firms are gearing to the student market, because they know that the student will choose in their line of work what they got used to in class. Having said that... the new HP35sII should have CHAIN, ALGEBRAIC (with pretty print), and RPN (let the user choose). It should compete with other student models out there... but it should be configurable for professional use by professional engineers and scientists. I know HP gets this... because that is how their 20b and 30b business calcs are configured NOW. If you haven't noticed the 20b and 30b calcs are powerful scientific calculators in their own right, and they can be set in CHAIN, ALGEBRAIC, or RPN modes (it could just as easily do pretty print, permitting the lcd is all points addressable).

<sigh, enough opinion for now>

Cheers,

marcus

Kind regards,
marcus
02-11-2015, 08:34 PM (This post was last modified: 02-11-2015 08:34 PM by Tim Wessman.)
Post: #22
 Tim Wessman Senior Member Posts: 2,270 Joined: Dec 2013
RE: HP 35s Checksum explained
(02-11-2015 06:55 PM)Tugdual Wrote:  Tim, please don't forget that >>>many<<< people but students use calculators. I

There is the crux of the issue. Please define >many< with evidence to back up your statements such that that the equation (roughly generalized):

desired_profitability < (price*many - NRE - (time*lost_opprotunity_cost) - COGS - marketing - certifications - ...)*fudge_factor_based_on_strategic_direction

Unfortunate, but that is how business works now. The same realities happen when small groups of people try to create the next cool product, the custom calculator of their dream, or any other thing. Finance don't play favorites.

Businesses tend to be averse to risk -large businesses even more-so- and barring a forceful personality head to override risk business will generally choose the safest path.

TW

Although I work for the HP calculator group, the views and opinions I post here are my own.
02-11-2015, 08:45 PM
Post: #23
 Tugdual Senior Member Posts: 755 Joined: Dec 2013
RE: HP 35s Checksum explained
(02-11-2015 08:34 PM)Tim Wessman Wrote:
(02-11-2015 06:55 PM)Tugdual Wrote:  Tim, please don't forget that >>>many<<< people but students use calculators. I

There is the crux of the issue. Please define >many< with evidence to back up your statements such that that the equation (roughly generalized):

desired_profitability < (price*many - NRE - (time*lost_opprotunity_cost) - COGS - marketing - certifications - ...)*fudge_factor_based_on_strategic_direction

Unfortunate, but that is how business works now. The same realities happen when small groups of people try to create the next cool product, the custom calculator of their dream, or any other thing. Finance don't play favorites.

Businesses tend to be averse to risk -large businesses even more-so- and barring a forceful personality head to override risk business will generally choose the safest path.
I know Tim and I'm not a marketing person neither am I in this business. But there is one thing that can be attempted: kickstart a project! You'll know if the project is viable before you even commit a dollar. Zero risk.
02-13-2015, 11:55 PM
Post: #24
 David Hayden Senior Member Posts: 372 Joined: Dec 2013
RE: HP 35s Checksum explained
(02-09-2015 10:36 PM)Tugdual Wrote:  I'm afraid this definitely concludes the question of CRC.
Now that we know the cause, is there a way to work around the problem? Is there a way to write a separate program that will compute a useful checksum? Maybe a clever way to force memory management to put equations in a specific location temporarily so that a common checksum will be computed?

Dave
02-14-2015, 05:58 AM
Post: #25
 MarkHaysHarris777 Senior Member Posts: 333 Joined: Jan 2015
RE: HP 35s Checksum explained
(02-13-2015 11:55 PM)David Hayden Wrote:
(02-09-2015 10:36 PM)Tugdual Wrote:  I'm afraid this definitely concludes the question of CRC.
Now that we know the cause, is there a way to work around the problem? Is there a way to write a separate program that will compute a useful checksum? Maybe a clever way to force memory management to put equations in a specific location temporarily so that a common checksum will be computed?

Dave

hi Dave, the solution to this glitch is to be consistent about the order in which programs vs equations are placed into memory. The chesksums are absolutely useful now. ... so long as the users are consistent: programs first, equations second.

marcus

Kind regards,
marcus
02-14-2015, 08:38 AM (This post was last modified: 02-14-2015 08:41 AM by Tugdual.)
Post: #26
 Tugdual Senior Member Posts: 755 Joined: Dec 2013
RE: HP 35s Checksum explained
There is one more thing I wanted to share regarding memory management. I mentioned earlier in this thread that I observed the memory was rearranged in some circumstances and I found this was related to 2 possible events: removing on EQN or earsing all EQN.
Let's see what happens...

We will be using simple program blocks that I will call PA for
Code:
LBL A 1
Starting with PA, PB, we find the following checksums:
Case 0:
Code:
 [MEMORY CLEAR] LBL A ->7991 1 LBL B -> 4CCE 1
Okay now let's start from scratch and enter PA,PC,PB
Code:
LBL A -> 7991 1 LBL C -> 5BBF 1 LBL B -> 43DD 1
Now we remove PC and we see that PA and PB kept the same checksums.
Call EQN and then CLEAR 3 (EQN) or simply create a new EQN and delete it.
Check again the checksums
Code:
PA -> 7991 PB -> 4CCE
What happened is that the literal allocation for C left a gap in memory and as soon as you suppress one or all EQNs, the 35s is trying to fill gaps and change the program pointers.
Unfortunately this doesn't really help because we still depend on pointers.
For example if you do this:
1. Enter PB
2. Up, Up
3. Enter PA

You end up with the same code as case 0 but the entry of literals was reversed and therefore pointers are swapped. Since pointer value is part of checksum calculation, you will end up with different checksums.
Code:
LBL A -> 7A1D 1 LBL B -> 4C42 1
Even if there was a way to sort all pointers, you would still depend on pointer values and therefore a separate LBL would still not have its own checksum code dependent.

The only correct way would be to ignore pointer and only include the literal string value (which is the case, it is included). As I said this is a major design flaw, I don't see a way to produce a memory independent checksum with this current design.
There is still one mystery, that is the actual calculation of checksum for the literals and EQN used in the code. I couldn't figure out exactly how this is calculated but I'm not really keen about spending time on this as it would be pretty useless.
02-14-2015, 08:44 AM
Post: #27
 Paul Dale Senior Member Posts: 1,714 Joined: Dec 2013
RE: HP 35s Checksum explained
(02-14-2015 05:58 AM)MarkHaysHarris777 Wrote:  hi Dave, the solution to this glitch is to be consistent about the order in which programs vs equations are placed into memory. The chesksums are absolutely useful now. ... so long as the users are consistent: programs first, equations second.

So I can I enter several programs with equations in them (which includes text prompts I somewhat suspect)? What if I don't want to clear my 30k of programs and equations to input a new one and verify the checksum?

Even though the checksum is somewhat consistent, it doesn't mean it is useful in practice.

- Pauli
02-14-2015, 08:57 AM
Post: #28
 Tugdual Senior Member Posts: 755 Joined: Dec 2013
RE: HP 35s Checksum explained
(02-14-2015 08:44 AM)Paul Dale Wrote:  Even though the checksum is somewhat consistent, it doesn't mean it is useful in practice.
Agreed. It is not random or machine dependent as initially suspected but definitely of no use.
 « Next Oldest | Next Newest »

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