storing value of a constant function, want recall / strange behaviour of Reference using a domain name like FIDETransposition

30 views
Skip to first unread message

Prof. Dr. Johannes Grabmeier

unread,
Jan 22, 2024, 7:46:51 AM1/22/24
to fricas...@googlegroups.com

Dear all,

1. following problem: I use Reference NNI to change internal values of a domain. A further constant function: init: () ->% depends of the changed values. It seems that FriCAS does not call the constant function again, but stores the old value of init(), then out of date. Non constant functions of course correctly use the changed values. How can I bring FriCAS to call and evaluate again the constant function with the updated values?

2. Another, very strange problem was noted:

The referenced values where in a domain called

)abbrev domain FIDETR FIDETransposition

Believe me or not: the changing of the referenced values did not work!

After long searching of the reasons I found: this depended on the name "FIDETransposition", i.e. the change to

)abbrev domain FIDETR FideTransposition

caused, that changing of referenced values work as expected! Can send an example, if someone is interested.

-- 
Mit freundlichen Grüßen

Johannes Grabmeier

Prof. Dr. Johannes Grabmeier, 
Köckstraße 1, D-94469 Deggendorf
Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
Fax: +49-(0)-991-2979592

Qian Yun

unread,
Jan 22, 2024, 7:51:05 AM1/22/24
to fricas...@googlegroups.com

On 1/22/24 20:46, Prof. Dr. Johannes Grabmeier wrote:
> Dear all,
>
> 1. following problem: I use Reference NNI to change internal values of a
> domain. A further constant function: init: () ->% depends of the changed
> values. It seems that FriCAS does not call the constant function again,
> but stores the old value of init(), then out of date. Non constant
> functions of course correctly use the changed values. How can I bring
> FriCAS to *call *and *evaluate* again the constant function with the
> updated values?
>
> 2. Another, very strange problem was noted:
>
> The referenced values where in a domain called
>
> )abbrev domain FIDETR FIDETransposition
>
> Believe me or not: the changing of the referenced values did not work!
>
> After long searching of the reasons I found: this depended on the name
> "FIDETransposition", i.e. the change to
>
> )abbrev domain FIDETR FideTransposition
>
> caused, that changing of referenced values work as expected! Can send an
> example, if someone is interested.
>

Yes, examples please, otherwise it's hard to debug.

Problem in 1 should not happen, because there are similar things in
FriCAS code base and they work well. So please show me the example.

- Qian

Prof. Dr. Johannes Grabmeier

unread,
Jan 22, 2024, 9:11:13 AM1/22/24
to fricas...@googlegroups.com
example to 1.:

after

)co iml

)co fidepermutationsINIT

one gets

(1) -> n1()$FideTransposition

   (1)  1
Type: NonNegativeInteger
(2) -> n2()$FideTransposition

   (2)  1
Type: NonNegativeInteger
(3) -> n()$FideTransposition

   (3)  2
Type: NonNegativeInteger
(4) -> init()$FideTransposition
   init() called using oneToN1 = [1]

   (4)  [1]
Type: FideTransposition
(5) -> set(3,5)$FideTransposition

   (5)  [3, 5]
Type: List(NonNegativeInteger)
(6) -> n1()$FideTransposition

   (6)  3
Type: NonNegativeInteger
(7) -> n2()$FideTransposition

   (7)  5
Type: NonNegativeInteger
(8) -> n()$FideTransposition

   (8)  8
Type: NonNegativeInteger
(9) -> init()$FideTransposition

   (9)  [1]
Type: FideTransposition

expected answer is [1,2,3]



Am 22.01.24 um 13:51 schrieb Qian Yun:
fidepermutationsINIT.spad
iml.spad
beispielFidetransformation.input

Ralf Hemmecke

unread,
Jan 22, 2024, 9:25:06 AM1/22/24
to fricas...@googlegroups.com
I am not quite sure what the "constant" in this line actually means (Is
that documented somewhere?), but intuitively it might be the sources of
your "problem".

https://github.com/fricas/fricas/blob/master/src/algebra/catdef.spad#L1498

Ralf

Prof. Dr. Johannes Grabmeier

unread,
Jan 22, 2024, 9:39:44 AM1/22/24
to fricas...@googlegroups.com
thanks, the rare instance of code for init() in the system, e.g. in
QuotienFieldCategory is as follows:

 if S has StepThrough then
    init() == init()$S / 1$S

my code says

init(): % ==

changes to

init: % ==

and

init: ==

both compile, but both do not change the wrong behaviour

Are there semantic differences between

f: constant -> %

versus

f: () -> %


Am 22.01.24 um 15:25 schrieb Ralf Hemmecke:

oldk1331

unread,
Jan 22, 2024, 9:42:10 AM1/22/24
to fricas-devel
Because init() uses oneToN1  which is a variable that is initialized only once when the Domain is created.

Try to make oneToN1 into a function.

- Qian

--
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 on the web visit https://groups.google.com/d/msgid/fricas-devel/76a5fc70-c37b-4502-9c5a-974a0d250d86%40grabmeier.net.

Prof. Dr. Johannes Grabmeier

unread,
Jan 22, 2024, 9:47:14 AM1/22/24
to fricas...@googlegroups.com

good suggestion, but I had that before and it does not help. You also see that init() is not called again, as it does not print out, that it is called. This is the problem, as it is not called, it neither can use a constant nor another function.

Am 22.01.24 um 15:42 schrieb oldk1331:

oldk1331

unread,
Jan 22, 2024, 10:00:22 AM1/22/24
to fricas-devel
The "constant" can cause the compiler to cache the result and return it directly next time, IIRC.

- Qian

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

Ralf Hemmecke

unread,
Jan 22, 2024, 10:13:22 AM1/22/24
to fricas...@googlegroups.com
On 1/22/24 16:00, oldk1331 wrote:
> The "constant" can cause the compiler to cache the result and return it
> directly next time, IIRC.

Oh... well... here it is documented.

https://github.com/fricas/fricas/blob/master/src/doc/ht/gloss.text#L161

Since that appears only under src/doc/ht, I am sure I have not included
it into book.pdf. :-(

Gosh! There is something to do.

Ralf

Prof. Dr. Johannes Grabmeier

unread,
Jan 22, 2024, 10:15:26 AM1/22/24
to fricas...@googlegroups.com

aha, this seems reasonable (but, who should know that?)

But, nevertheless problem is not solved: I now added a new exported function

init : () -> %

BUT: same behaviour,

the code

 init(): % ==
   if mLP 0 then print hconcat [toOF "init() called using oneToN1 = ", oneToN1 :: OF]

   per oneToN (deref n1Ref)

still seems to refer to the one inherited from StepThrough, namely

init: constant -> %

Question: how can these 2 function be distinguished?

And even worse:

I cannot use the category StepThrough in my case, because the code in the category uses the

init()-function with "contant". Obviously, implementing

init: constant -> %

there, one has not thought about the neccessity to switch that off in cases where the

domain has feature to change internal variables.

That is not satisfactory, would need a possibility to force the system at runtime to evaluate the function again, although it is defined with "constant".

Am 22.01.24 um 16:00 schrieb oldk1331:

Qian Yun

unread,
Jan 22, 2024, 7:19:38 PM1/22/24
to fricas...@googlegroups.com
++ A class of objects which can be 'stepped through'.
++ Repeated applications of \spadfun{nextItem} is guaranteed never to
++ return duplicate items and only return "failed" after exhausting
++ all elements of the domain.
++ This assumes that the sequence starts with \spad{init()}.
++ For infinite domains, repeated application
++ of \spadfun{nextItem} is not required to reach all possible domain
elements
++ starting from any initial element.


From the documentation of StepThrough, it is required that "init()"
stays the same.

Does your domain really need to implement StepThrough?

BTW, for those "Domain variables", there is no need to use Reference:
see commit 9dfdbc4cedc2d4a76230f707b238efe201d0a410 for example.

- Qian
>>     <mailto:fricas-devel%2Bunsu...@googlegroups.com>.
>>     To view this discussion on the web visit
>>
>> https://groups.google.com/d/msgid/fricas-devel/3cb26dbf-3d60-47f4-9490-7b0a2b530e69%40grabmeier.net.
>>
>> --
>> 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 on the web visit
>> https://groups.google.com/d/msgid/fricas-devel/CAGBJN916frH6W2u1JoS%3DBep-rA0woUpLTw3GQsx7LR9eUYiYaA%40mail.gmail.com <https://groups.google.com/d/msgid/fricas-devel/CAGBJN916frH6W2u1JoS%3DBep-rA0woUpLTw3GQsx7LR9eUYiYaA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>

Waldek Hebisch

unread,
Jan 22, 2024, 10:51:49 PM1/22/24
to fricas...@googlegroups.com
On Mon, Jan 22, 2024 at 04:15:23PM +0100, Prof. Dr. Johannes Grabmeier wrote:
> aha, this seems reasonable (but, who should know that?)
>
> But, nevertheless problem is not solved: I now added a new exported function
>
> init : () -> %
>
> BUT: same behaviour,

AFAICS behaviour changes when you modify STEP.spad to remove 'constant',
recompile and than recompile your files.

However, you probably should re-think your design. Without
mutation you can have several iterations going in parallel
(possibly in different functions). With your approach
mutation to doman breaks all iterations in progress.

In general, math objects should be immutable, that is are
created once (possibly using mutation) during creation and
then used as long as needed. Mutation of types should not
break this, that is valid math object should be effectively
"the same" even is domain is modified. So mutation for
caching or change of print format are OK. Also, domains
that effectively work as finite approximations to infite
object by using bigger and bigger finite objects are OK.

Coming back to your domain: change to StepTrough would probably
give behaviour that you want. But such change is inappropriate,
as currently StepTrough behaves correctly with domains that
respect FriCAS design. And even if 'init' problem would be
reloved as you like your domain will not play nice with the
rest of FriCAS library.

From your code it is not clear what you really want/need.
Iteration could be done using generators (several years ago
I posted a simple implementation of generators for FriCAS).
Note that with generators you can have several ways of
iterationg other the same domain. Unlike StepTrough there
is no need to create new domain only to have new iteration
pattern (of course you need separate implementations so
possibly separate package with generator(s), but base
domain stays the same). Or maybe you can use streams (you
can think of streams as variant of generators that remembers
all values that were produced).

If you need more than iteration there is a question what operations
you need and do they depend on parameters? If other operations
are independent of parameters, than things are easy. If
operations depend on parameters than storing parameters
together with elements allows single domain. Or use FriCAS
classics, that is parametrized types.

> I cannot use the category StepThrough in my case, because the code in the
> category uses the
>
> init()-function with "contant". Obviously, implementing
>
> init: constant -> %
>
> there, one has not thought about the neccessity to switch that off in cases
> where the
>
> domain has feature to change internal variables.

As I wrote changing _essential_ internal variables is really incompatible
with FriCAS design.

--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages