Invalid use of underscores in pattern: search_constructors (search_operation)

13 views
Skip to first unread message

Grégory Vanuxem

unread,
Apr 5, 2026, 10:27:04 AMApr 5
to fricas...@googlegroups.com
Hello,

search_operations("search_constructors")$BrowserInformation
loop with "Invalid use of underscores in pattern: search_constructors" output,
is it what is expected?

Greg

Waldek Hebisch

unread,
Apr 5, 2026, 11:35:13 AMApr 5
to fricas...@googlegroups.com
Thanks for mentioning this. Unfortunately, pattern matching still
uses old code and this code has rather peculiar handling of
underscores, in particular signaling errors like this. Probably
the simplest way to fix such problems is to write new pattern
matching code. I concentrated my attention on different problems,
but probably it is time to handle this one too.

BTW: old browse code had alternative paths, so such patterns
sometimes worked, but new code is simpler and in particular
'search_operations' has no alternative paths, it always is
doing the same thing (that is match pattern to each operation
name).

--
Waldek Hebisch

Grégory Vanuxem

unread,
Apr 5, 2026, 1:10:09 PMApr 5
to fricas...@googlegroups.com
Thanks for this response, I will look forward to your modifications.

Greg
> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/adKBLvfNvs-pnbsT%40fricas.org.

Waldek Hebisch

unread,
May 27, 2026, 2:11:50 PM (5 days ago) May 27
to fricas...@googlegroups.com
On Sun, Apr 05, 2026 at 04:26:25PM +0200, Grégory Vanuxem wrote:
I have now implemented new matching code. You can find it at:

http://wiki.fricas.org/public/match.spad

After compiling you can do things like:

a := parse_pattern("a*l or b*d", true)

LISP output:
(0 0 or (1 UNPRINTABLE . UNPRINTABLE) (1 UNPRINTABLE . UNPRINTABLE))
Type: Union(LogicalMatchingAutomaton,...)
(2) -> do_match(a, "arl")

(2) true
Type: Boolean
(3) -> do_match(a, "brd")

(3) true
Type: Boolean
(4) -> do_match(a, "brl")

(4) false
Type: Boolean

Note: I did not implement coercion to OutputForm, that is why there
is "LISP output" and UNPRINTABLE above.

Matching uses finite automation. Core automation code is general,
that is it supports arbitrary nondeterministic finite automaton.
However, there is parser for patterns and it supports only
kinds of patterns previously available in HyperDoc. In principle
we could add more features, like character ranges and general
regular expressions. Efficient support for character ranges
probably will need some change to core, other things are mostly
matter of appropriate parser and construction functions.

This code uses nondeterministic finite automaton, so can
support true regular expressions, but some things offered
by "regular expressions" in pupular libraries can not be
done by finite automaton and require more powerful
(and more expensive) paradigm like backtracking search.
Such extentions are beyond scope of current implementation.

As nondeterministic finite automatons go, this implementation
spends substantial time in SPADCALL-s, so probably is
significantly less efficient than lower level code. Still,
on nontrivial patterns it seem to be several times faster
than matching code in 'match.boot' that is currently used
by HyperDoc.

I have also patch to BRINFO, it is at:

http://wiki.fricas.org/public/BRINFO.diff

After compiling patched BRINFO things like:

search_operations("search_constructors")$BrowserInformation
search_operations("__*")$BrowserInformation
search_operations("_and")$BrowserInformation

should give sensible results. Underscore works as escape in the
pattern, so that following character have literal meaning. This
allows searching for multiplication and possibly (if we add them)
for other characters that have special meaning in patterns.

--
Waldek Hebisch

Grégory Vanuxem

unread,
May 28, 2026, 11:35:27 AM (4 days ago) May 28
to fricas...@googlegroups.com
Hello,

That works very nicely! Compiling, first, match.spad, and patching
BRINFO.spad though I obtain this at the root directory of FriCAS:

└─$ cat BRINFO.diff |patch -p3
patching file src/algebra/BRINFO.spad
Hunk #3 succeeded at 242 (offset 10 lines).
Hunk #4 succeeded at 885 (offset 37 lines).
Hunk #5 succeeded at 965 with fuzz 2 (offset 43 lines).
Hunk #6 succeeded at 986 (offset 43 lines).
Hunk #7 succeeded at 996 (offset 43 lines).

I obtain desired results (I am using a simple interface to
BrowserInformation, SDOC:
https://github.com/gvanuxem/jlfricas/blob/master/src/algebra/sdoc.spad):

(4) -> operationDocumentation parse_pattern


parse_pattern(s, downcase) parses s and returns corresponding
matching automaton. It returns "failed" in case
of syntax error. If downcase is true then all literal characters in
s are converted to lower case, otherwise c
ase is retained.
Signature: (String,Boolean)->Union(LogicalMatchingAutomaton,"failed")
From: LogicalRegularExpressionMatch

(8) -> a := parse_pattern("a*l or b*d", true)

LISP output:
(0 0 or (1 UNPRINTABLE . UNPRINTABLE) (1 UNPRINTABLE . UNPRINTABLE))

Type: Union(LogicalMatchingAutomaton,...)
(9) -> do_match(a, "brd")

(9) true

I tried also parse_pattern("a.*l or b.*d", true) but as you said it is
beyond scope of current implementation.


(10) -> operationDocumentation do_match


do_match(a, s) returns true if and only if a matches s.
Signature: (%,String)->Boolean
From: BasicMatchingAutomaton


do_match(a, s) returns true if and only if a matches s.
Signature: (%,String)->Boolean
From: LogicalMatchingAutomaton


do_match(p, s) returns true if and only if s matches to pattern p.
Signature: (LogicalMatchingAutomaton,String)->Boolean
From: BrowserInformation

Thanks for this work, I hope it will be included shortly.

Greg
> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/ahcz48Ptx5oYf022%40fricas.org.
Reply all
Reply to author
Forward
0 new messages