Proposal : List of regular expressions for numeric syntax on different HP calculators

06072019, 05:25 PM
Post: #1




Proposal : List of regular expressions for numeric syntax on different HP calculators
I'm interested in the syntax of what the user can enter as a number in various HP calculators. For the HP48 series, I think the regular expression is :
((([+]?[09]+(\.)?[09]*)([+]?[09]*(\.)?[09]+))([eE](([+]?[09]+(\.)?[09]*)([+]?[09]*(\.)?[09]+)))?) which is quite convoluted. Here's a short Perl script that presents it in a more understandable way : Code: #!/usr/bin/perl I'm interested in how the regular expressions used to match the user entered number formats differ in different HP Calculators. Perhaps we could compile a list of the different regular expressions Regards, Jonathan Aeternitas modo est. Longa non est, paene nil. 

06072019, 05:44 PM
Post: #2




RE: Proposal : List of regular expressions for numeric syntax on different HP calculators
I fear though, that because most of the numeric representations are very general, there will only be minor variations. So, maybe not a very interesting proposal after all :/
Regards, Jonathan Aeternitas modo est. Longa non est, paene nil. 

06072019, 06:26 PM
Post: #3




Proposal : List of regular expressions for numeric syntax on different HP calculators
(06072019 05:25 PM)Jonathan Busby Wrote: For the HP48 series, I think the regular expression is : I think the above might be incorrect because it allows a trailing decimal separator ( eg. 9.e9 ), but that can be fixed. Also, the decimal separator is just "." as including "," would be redundant for the purposes of explaining the regular expression. Regards, Jonathan Aeternitas modo est. Longa non est, paene nil. 

06072019, 06:55 PM
Post: #4




RE: Proposal : regular expressions for numeric syntax on different HP calculators
(06072019 05:25 PM)Jonathan Busby Wrote: For the HP48 series, I think the regular expression is : Hi, Jonathan: I only have a HP12C, but I don't think decimal points allowed on the exponent field. 

06072019, 07:24 PM
Post: #5




Proposal : List of regular expressions for numeric syntax on different HP calculators
(06072019 06:55 PM)Albert Chan Wrote:(06072019 05:25 PM)Jonathan Busby Wrote: For the HP48 series, I think the regular expression is : You are indeed correct! The regular expression should then be : ((([+]?[09]+(\.)?[09]*)([+]?[09]*(\.)?[09]+))([eE][09]+)?) Regards, Jonathan Aeternitas modo est. Longa non est, paene nil. 

06072019, 08:01 PM
Post: #6




Proposal : List of regular expressions for numeric syntax on different HP calculators
I've been notified that the above regular expression is incorrect. It seems I took out the optional sign after the exponent. Here is the corrected version :
((([+]?[09]+(\.)?[09]*)([+]?[09]*(\.)?[09]+))([eE][+]?[09]+)?) Regards, Jonathan Aeternitas modo est. Longa non est, paene nil. 

06072019, 09:00 PM
Post: #7




RE: Proposal : List of regular expressions for numeric syntax on different HP calculators
Has anybody ever attacked the problem from the other side: given an adequately long list of strings, compute a regular expression matching all of them.
Of course the strings must have a traitd'union and not purely random, e.g. number representation by a calc, coordinates, plate licenses... 

06082019, 05:44 AM
Post: #8




RE: Proposal : List of regular expressions for numeric syntax on different HP calculators
Are you interested in the resulting number format or the user's entry sequence? It looks like the final result but one never knows.
You've missed the finite number of digits that can be entered, the expressions posted so far allow any number of digits which simply isn't possible on a calculator. No calculator that I'm aware of allows a leading plus sign. Minus or nothing both for the mantissa and exponent. If you are following the user's key sequence, then e.g. the +/ key can be pressed at any time and as many times desired. Regular expressions for reals are tricky Pauli 

06082019, 05:50 AM
Post: #9




RE: Proposal : List of regular expressions for numeric syntax on different HP calculators
(06072019 09:00 PM)JoJo1973 Wrote: Has anybody ever attacked the problem from the other side: given an adequately long list of strings, compute a regular expression matching all of them. List all of the strings as the expression: string_1string_2...string_n. A state minimisation is usually done as part of the finite automata construction. Immediate optimal matcher. Well almost. Strictly, for a series of constant strings like this an entirely different algorithm based on a many in parallel BoyerMoore style approach is used instead. Pauli 

06082019, 07:57 AM
Post: #10




RE: Proposal : List of regular expressions for numeric syntax on different HP calculators
On the HP 41 series the sequence 'E3' is possibly (synthetically). It's value is 1000. From the keyboard, it works normally.
I don't have a calculator to check if '.' is legal alone but I suspect it would be. In key sequences, a leading '+/' doesn't start number entry.... Pauli 

01272020, 05:40 PM
(This post was last modified: 01272020 06:58 PM by Jonathan Busby.)
Post: #11




RE: List of regular expressions for numeric syntax on different HP calculators
Sorry for the belated reply.
(06082019 05:50 AM)Paul Dale Wrote: List all of the strings as the expression: string_1string_2...string_n. A state minimisation is usually done as part of the finite automata construction. Immediate optimal matcher. Well, actually, constructing a minimal DFA from a set of strings is NPComplete and is "A.I.hard" **if** the set of strings is part of a larger pattern that must be matched or inferred, otherwise, it's easy but the DFA will **only** match strings that it's seen in its "training set". It can be shown that it is equivalent to Grammar Induction. The problem is what to do if the sets of strings do not generate the needed states for the optimal DFA in terms of a larger pattern space, if not all patterns have been seen  there may be an infinite number of patterns that should match or not match but do anyways, at least without constraints. I've seen the above problem being tackled with A.I. genetic programming and neural nets. For example, see here : http://regex.inginf.units.it/ . I tried, as training examples for the genetic algorithm, "abcdefghijklmnopqrstuvwxyz" and "0123456789" and got a regex of "[^\d ]++" . Although this matches the above two strings, it also matches garbage  it would need a very huge training set to accurately match anything. Quote:Well almost. Strictly, for a series of constant strings like this an entirely different algorithm based on a many in parallel BoyerMoore style approach is used instead. The only problem with the above is that, unless a slightly "fuzzy" search is used, only the strings seen so far will be matched. In the case of a DFA generated with grammar induction, it would be able to match strings from its inferred grammar, although, there may be many false positives and negatives, unless some more "fuzziness" is added, such as in agrep or Perl's "String::Approx" . Regards, Jonathan Aeternitas modo est. Longa non est, paene nil. 

« Next Oldest  Next Newest »

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