Proposal : List of regular expressions for numeric syntax on different HP calculators
06-07-2019, 05:25 PM
Post: #1
 Jonathan Busby Member Posts: 237 Joined: Nov 2014
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 :

((([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+))([eE](([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+)))?)

which is quite convoluted. Here's a short Perl script that presents it in a more understandable way :

Code:
#!/usr/bin/perl $a = "([+-]?[0-9]+(\\.)?[0-9]*)";$b = "([+-]?[0-9]*(\\.)?[0-9]+)"; $c = "($a|$b)";$d = "($c([eE]$c)?)"; while(<STDIN>) {     /$d/; print$1; }

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.
06-07-2019, 05:44 PM
Post: #2
 Jonathan Busby Member Posts: 237 Joined: Nov 2014
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.
06-07-2019, 06:26 PM
Post: #3
 Jonathan Busby Member Posts: 237 Joined: Nov 2014
Proposal : List of regular expressions for numeric syntax on different HP calculators
(06-07-2019 05:25 PM)Jonathan Busby Wrote:  For the HP48 series, I think the regular expression is :

((([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+))([eE](([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+)))?)

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.
06-07-2019, 06:55 PM
Post: #4
 Albert Chan Senior Member Posts: 1,646 Joined: Jul 2018
RE: Proposal : regular expressions for numeric syntax on different HP calculators
(06-07-2019 05:25 PM)Jonathan Busby Wrote:  For the HP48 series, I think the regular expression is :

((([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+))([eE](([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+)))?)

Hi, Jonathan:

I only have a HP-12C, but I don't think decimal points allowed on the exponent field.
06-07-2019, 07:24 PM
Post: #5
 Jonathan Busby Member Posts: 237 Joined: Nov 2014
Proposal : List of regular expressions for numeric syntax on different HP calculators
(06-07-2019 06:55 PM)Albert Chan Wrote:
(06-07-2019 05:25 PM)Jonathan Busby Wrote:  For the HP48 series, I think the regular expression is :

((([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+))([eE](([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+)))?)

Hi, Jonathan:

I only have a HP-12C, but I don't think decimal points allowed on the exponent field.

You are indeed correct! The regular expression should then be :

((([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+))([eE][0-9]+)?)

Regards,

Jonathan

Aeternitas modo est. Longa non est, paene nil.
06-07-2019, 08:01 PM
Post: #6
 Jonathan Busby Member Posts: 237 Joined: Nov 2014
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 :

((([+-]?[0-9]+(\.)?[0-9]*)|([+-]?[0-9]*(\.)?[0-9]+))([eE][+-]?[0-9]+)?)

Regards,

Jonathan

Aeternitas modo est. Longa non est, paene nil.
06-07-2019, 09:00 PM
Post: #7
 JoJo1973 Member Posts: 100 Joined: Apr 2016
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 trait-d'union and not purely random, e.g. number representation by a calc, coordinates, plate licenses...
06-08-2019, 05:44 AM
Post: #8
 Paul Dale Senior Member Posts: 1,725 Joined: Dec 2013
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
06-08-2019, 05:50 AM
Post: #9
 Paul Dale Senior Member Posts: 1,725 Joined: Dec 2013
RE: Proposal : List of regular expressions for numeric syntax on different HP calculators
(06-07-2019 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_1|string_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 Boyer-Moore style approach is used instead.

Pauli
06-08-2019, 07:57 AM
Post: #10
 Paul Dale Senior Member Posts: 1,725 Joined: Dec 2013
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
01-27-2020, 05:40 PM (This post was last modified: 01-27-2020 06:58 PM by Jonathan Busby.)
Post: #11
 Jonathan Busby Member Posts: 237 Joined: Nov 2014
RE: List of regular expressions for numeric syntax on different HP calculators

(06-08-2019 05:50 AM)Paul Dale Wrote:  List all of the strings as the expression: string_1|string_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 NP-Complete 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 Boyer-Moore 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)