Why is it necessary to call "value" for a variable to be interpreted as being in a ring?

[Michael DeBellevue]

I am working on a project to implement simplicial rings.  Their basic data is that of a sequence of rings with maps between them.  The constructor builds them as polynomial rings over a base ring with common variable table (e.g., the first ring will be R[T_(0,0),...], the next R[T_(1,0), ...], etc).  

When building maps, I have found it necessary to include "value" before any reference to the variables of the rings, otherwise the map function complains that it doesn't know how to promote an indexed variable to the ring in question.   I think that the issue is "contained" in the sense that when the user is interacting with the resulting simplicial ring and types T_(0,0), it is interpreted as being in the ring in the normal manner that one would expect.  Still, I'm curious about what's causing this behavior and if there's a way to remove the need to call "value".  I'm concerned that if I don't correct this problem at the source, it may cause other issues that are difficult to predict and troubleshoot (it took quite a while to find this "value" solution in the first place).

I think that it might have something to do with needing to run globalAssignment on the data type or getSymbol on the variable table symbol, but neither of these fix the problem on their own.

I've created a minimal working example (attached).  In the example code, extendBoxedRing yields an error and adding "value" as in extendBoxedRing2 fixes the problem.  I've attached a screenshot demonstrating the behavior .  I commented out the aforementioned attempts to use globalAssignment and getSymbol as they didn't seem to do anything.

Thanks,

Michael

[Mahrud Sayrafi]

Hi Michael,

I think this is a bug that can be resolved by adding the missing method:

    promote(IndexedVariable, RingElement) := RingElement => (m, R) -> promote(value m, R)

Then you wouldn't need to call "value" yourself every time.

A quick remark that depending on what lists L are allowed, the line

    rings#i = R[T_(i,L#0)..T_(i,L#n)];

might not be doing what you want it to do.

For instance if L={2,1} then QQ[T_(L_0)..T_(L_1)] has no variables.

Best,

Mahrud

--
You received this message because you are subscribed to the Google Groups "Macaulay2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to macaulay2+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macaulay2/c5786cc1-cda9-44a5-9909-d535fc28c464n%40googlegroups.com.

[Michael DeBellevue]

Mahrud,

Thanks for the suggestion, that should fix this everywhere all at once.

I agree, the use of lists in the minimal working example function is likely to lead to problems.  It's not really similar to what's going on in my actual application though, fortunately.  I think I wrote it that way because at some point I thought that non-integer indexing might be part of the cause, but this turned out to not be the case.

Best,

Michael

You received this message because you are subscribed to a topic in the Google Groups "Macaulay2" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/macaulay2/WoeXsOHPvs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to macaulay2+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macaulay2/CAA3cHpuRghLS0tFzBHt31Brd_Zt5FzmwU%2ByMNFNr3HJdT4x1mw%40mail.gmail.com.