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

[Jonathan Busby]

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

[Jonathan Busby]

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

[Jonathan Busby]

(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

[Albert Chan]

(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.

[Jonathan Busby]

(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

[Jonathan Busby]

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

[JoJo1973]

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...

[Paul Dale]

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

[Paul Dale]

(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

[Paul Dale]

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

[Jonathan Busby]

Sorry for the belated reply.

(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