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
|
|||
|
|||
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"... 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
|
|||
|
|||
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 HP, the views and opinions I post here are my own. |
|||
02-11-2015, 08:45 PM
Post: #23
|
|||
|
|||
RE: HP 35s Checksum explained
(02-11-2015 08:34 PM)Tim Wessman Wrote: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-11-2015 06:55 PM)Tugdual Wrote: Tim, please don't forget that >>>many<<< people but students use calculators. I |
|||
02-13-2015, 11:55 PM
Post: #24
|
|||
|
|||
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
|
|||
|
|||
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? 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
|
|||
|
|||
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 Case 0: Code:
Code: LBL A -> 7991 Call EQN and then CLEAR 3 (EQN) or simply create a new EQN and delete it. Check again the checksums Code: PA -> 7991 Unfortunately this doesn't really help because we still depend on pointers. For example if you do this:
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 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
|
|||
|
|||
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
|
|||
|
|||
RE: HP 35s Checksum explained | |||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 6 Guest(s)