function depending on domain

[Ralf Hemmecke]

Hi Waldek,

I am about to design a function that depends on a domain and a few other
parameters.

Cat: Category == with
foo?: Integer -> Boolean
..
D1: Cat == add ...
D2: Cat == add ...

Dom(): with
bar?: (Cat, Integer) -> Integer
add
blah(x: %): Integer == ...
bar(D: Cat, n: Integer, x: %): Integer ==
k: Integer := blah(x, n)
if (foo? $ D)(k) then 1 else 0

I am pretty sure that this is possible. I just want to ask whether from
your point of view this causes any speed penalties?

In my current idea I would not want to put that dependency into the
arguments of Dom. It is rather that "bar" counts as an additional
feature that is not so important. I also don't want to move bar to a
separate package.

Thank you in advance
Ralf

[Waldek Hebisch]

On Sun, Dec 07, 2025 at 04:12:21PM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> Hi Waldek,
>
> I am about to design a function that depends on a domain and a few other
> parameters.
>
> Cat: Category == with
> foo?: Integer -> Boolean
> ..
> D1: Cat == add ...
> D2: Cat == add ...
>
> Dom(): with
> bar?: (Cat, Integer) -> Integer
> add
> blah(x: %): Integer == ...
> bar(D: Cat, n: Integer, x: %): Integer ==
> k: Integer := blah(x, n)
> if (foo? $ D)(k) then 1 else 0
>
> I am pretty sure that this is possible. I just want to ask whether from your
> point of view this causes any speed penalties?

Yes. Normally result of lookup for functions are cached. But such
construct means that before each call insted of actually calling
'foo?' FriCAS runtime will first need to do full lookup, which costs
you some milliseconds. or tens of milliseconds. Negligible if you
do a single call. Perfomance killer if done in a tight loop.

Theoretically there is still some possibility for caching, but
currently variable domain is Spad means full lookup for each call.

> In my current idea I would not want to put that dependency into the
> arguments of Dom. It is rather that "bar" counts as an additional feature
> that is not so important. I also don't want to move bar to a separate
> package.
>
> Thank you in advance
> Ralf

--
Waldek Hebisch

[Ralf Hemmecke]

Dear Waldek,

thank you for your answer.

How is the situation for a definition

baz?: Cat -> Integer -> Integer
baz?(D: Cat): Integer -> Integer ==
(n: Integer, x: %): Integer +->

k: Integer := blah(x, n)
if (foo? $ D)(k) then 1 else 0

and in places where I use baz?, I do it like this

fun: (%, Integer) -> Integer := baz?(D1)
for i in 1..10 repeat res := res + fun(x, i)

would that still cost more or do I (with this assignment) prevent the
multiple lookups of foo? $ D1. I think

Ralf

[Ralf Hemmecke]

Dear Waldek,

it seems that I was too hopeful.

Unfortunately, the attached program give the following output.
It seems that the interpreter is unable to check a domain-evaluating
function parameter for its correct type. :-(

Can this be easily fixed?

Thank you
Ralf

===================================================

%%% (1) -> d: Dom := 1

(1) 1

Type: Dom
%%% (2) -> [baz1(3)(d), baz2(5)(d)]

(2) [1, 2]
Type: List(PositiveInteger)
%%% (3) -> bar?(D1,3)(d)
There are 1 exposed and 0 unexposed library operations named bar?
having 2 argument(s) but none was determined to be applicable.
Use HyperDoc Browse, or issue
)display op bar?
to learn more about the available operations. Perhaps
package-calling the operation or using coercions on the arguments
will allow you to apply the operation.

Cannot find a definition or applicable library operation named bar?
with argument type(s)
Type
PositiveInteger

Perhaps you should use "@" to indicate the required return type,
or "$" to specify which version of the function you need.

%%% (3) -> (bar?$Dom)

(3) theMap(DOM;bar?;CIM;2,45)
Type: ((Cat, Integer) -> (Dom -> Boolean))
%%% (4) -> (bar?$Dom)(D1,4)
There are 1 exposed and 0 unexposed library operations named bar?
having 2 argument(s) but none was determined to be applicable.
Use HyperDoc Browse, or issue
)display op bar?
to learn more about the available operations. Perhaps
package-calling the operation or using coercions on the arguments
will allow you to apply the operation.

Cannot find a definition or applicable library operation named bar?
with argument type(s)
Type
Integer

Perhaps you should use "@" to indicate the required return type,
or "$" to specify which version of the function you need.

[Waldek Hebisch]

On Tue, Dec 09, 2025 at 08:57:21AM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> Dear Waldek,
>
> it seems that I was too hopeful.
>
> Unfortunately, the attached program give the following output.
> It seems that the interpreter is unable to check a domain-evaluating
> function parameter for its correct type. :-(
>
> Can this be easily fixed?

Probably not. Interpreter type checking in many places ignores
categories, using 'Type' instead. I would have to investigate
deeper, but at first glance the problem you see is that interpteter
uses 'Type' and function declaration has more specific category.

> --
> 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/6ac741f1-49c4-4709-8962-f5a76203c3f3%40hemmecke.org.

> )abbrev category CAT Cat
> Cat: Category == with
> foo: Integer -> Integer
>
> )abbrev domain DOM1 D1
> D1: Cat == add
> foo(n: Integer) == 1
>
> )abbrev domain DOM2 D2
> D2: Cat == add
> foo(n: Integer) == 2
>
> )abbrev domain DOM Dom
> Dom(): Join(IntegerNumberSystem, CoercibleTo Integer) with
> bar?: (Cat, Integer) -> % -> Boolean
> baz1: Integer -> % -> Integer
> baz2: Integer -> % -> Integer
> == Integer add
> Rep ==> Integer
> coerce(x: %): Integer == x pretend Integer
> bar?(D: Cat, n: Integer): % -> Boolean == (x: %): Boolean +->
> foo(n+(x::Integer))$D = 1
> baz1(n: Integer): % -> Integer == (x: %): Integer +-> foo(n+(x::Integer))$D1
> baz2(n: Integer): % -> Integer == (x: %): Integer +-> foo(n+(x::Integer))$D2


--
Waldek Hebisch

[Ralf Hemmecke]

Waldek,

thank you for this answer.

> Interpreter type checking in many places ignores
> categories, using 'Type' instead. I would have to investigate
> deeper, but at first glance the problem you see is that interpteter
> uses 'Type' and function declaration has more specific category.

I think, it makes sense, to add this problem as an issue on github (as a
link to fricas-devel), even if it will not be fixed in the very near
future. But bit by bit I would like to have *one* place to which I can
refer (or direct other people) if they stumple upon the same issue.
There is too much other noise in the mailing list.

Agreed? (Maybe I should just do and not ask for permission.)

Ralf

[Waldek Hebisch]

OK. I admit that from my point of view Github usability was
decreasing in last few years, so I am not enthusiastic about
putting more things at Github. But my view should not stop
you (or other folks) from doing that you (or they) think is
useful.

--
Waldek Hebisch