Some issues around `image_fn`

[mjrodgers]

I'm in the process of moving MapFromFunc from Hecke into AbstractAlgebra as a replacement for Generic.FunctionalMap and I'm running into some problems with how images are computed using image_fn.

It seems like throughout AA/Nemo/Hecke, often the image of an element a under a map m is computed by calling image_fn(m)(a). But not all Map types have a defined image_fn method, this is only guaranteed for <: FunctionalMap. For example, when we compose two arbitrary maps we get a Generic.CompositeMap which has no image_fn, though we can compute images with it.

This leads to further problems when a Map type wraps another Map, for example a MapWithSection or MapWithRetraction f can wrap an arbitrary map::AbstractAlgebra.Map, and then image_fn(f) = image_fn(f.map); in some ways this is fine, we just get an error if there is not a defined image_fn, except if we want to compute f(a) it delegates to image_fn(f)(a) which will throw an error.

I see a couple of possible solutions:

• the HeckeMap type has a fallback, if there is not an image_function stored then it just creates one

function image_function(f::Map(HeckeMap))
  if isdefined(f.header, :image)
    return f.header.image
  else
    return x -> image(f, x)
  end
end

and we could just do this for arbitrary maps as well.

• maybe a better solution is just not to compute images using image_fn by default, especially for map types that wrap other maps. For example, I am working around the issues with MapWithSection/MapWithRetraction/CompositeMap by applying the wrapped maps directly instead of using image_fn, but I find this issue also in Nemo (FinFieldMorphism and FinFieldPreimage). Actually I only find one instance in Hecke or using image_fn and none in Oscar.

TL;DR : Do we need to make sure that every Map can return an image_fn? Or should we instead be more careful to avoid using image_fn to compute images when we aren't sure this method will be defined?

[fieker]

On Fri, Jul 03, 2026 at 01:57:38AM -0700, Morgan Rodgers wrote: mjrodgers created an issue (Nemocas/AbstractAlgebra.jl#2453) I'm in the process of moving `MapFromFunc` from Hecke into AbstractAlgebra as a replacement for `Generic.FunctionalMap` and I'm running into some problems with how images are computed using `image_fn`. It seems like throughout AA/Nemo/Hecke, often the image of an element `a` under a map `m` is computed by calling `image_fn(m)(a)`. But not all `Map` types have a defined `image_fn` method, this is only guaranteed for `<: FunctionalMap`. For example, when we compose two arbitrary maps we get a `Generic.CompositeMap` which has no `image_fn`, though we can compute images with it. This leads to further problems when a `Map` type wraps another `Map`, for example a `MapWithSection` or `MapWithRetraction` `f` can wrap an arbitrary `map::AbstractAlgebra.Map`, and then `image_fn(f) = image_fn(f.map)`; in some ways this is fine, we just get an error if there is not a defined `image_fn`, except if we want to compute `f(a)` it delegates to `image_fn(f)(a)` which will throw an error. I see a couple of possible solutions: - the `HeckeMap` type has a fallback, if there is not an `image_function` stored then it just creates one ```julia function image_function(f::Map(HeckeMap)) if isdefined(f.header, :image) return f.header.image else return x -> image(f, x) end end ``` and we could just do this for arbitrary maps as well. - maybe a better solution is just not to compute images using `image_fn` by default, especially for map types that wrap other maps. For example, I am working around the issues with `MapWithSection`/`MapWithRetraction`/`CompositeMap` by applying the wrapped maps directly instead of using `image_fn`, but I find this issue also in Nemo (`FinFieldMorphism` and `FinFieldPreimage`). Actually I only find one instance in `Hecke` or using `image_fn` and none in Oscar. TL;DR : Do we need to make sure that every `Map` can return an `image_fn`? Or should we instead be more careful to avoid using `image_fn` to compute images when we aren't sure this method will be defined?

I think it is even worse: there might actually be no way to compute images at all... maybe only preimages are possible, or, extending to categories, neither as this are not set maps... (don't know if this was helpful)

…

-- Reply to this email directly or view it on GitHub: #2453 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[mjrodgers]

I think it is even worse: there might actually be no way to compute
images at all... maybe only preimages are possible, or, extending to
categories, neither as this are not set maps...

Hm ok. Then I think I will delegate computing f(a) to f.map(a) for the cases where f wraps map, that way map can compute this image any way it knows how (and can throw its own error if it can't). This may not be perfect but will at least fix the cases where map does know how to compute an image but doesn't have an image_fn.

[mjrodgers]

Sort of related to this issue, can either @fieker or @thofma help me with this - this method is in src/generic/Map.jl

function compose(f::Map(FunctionalMap){D, U}, g::Map(FunctionalMap){U, C}) where {D, U, C}
   check_composable(f, g)
   return FunctionalCompositeMap(f, g)
end

Reading about FunctionalCompositeMap in the docs on the Map Interface, I think this is supposed to apply to f and g of type Map{D,U, <:FunctionalMap, S} and Map{U,C, <:FunctionalMap, T, respectively. But since the code is in the Generic module, I think it is instead being defined only for f and g of types Map{D,U, FunctionalMap, Generic.FunctionalMap} and Map{U,C, FunctionalMap, Generic.FunctionalMap instead.

Am I understanding this correctly? (This is related because we do have an image_fn for Generic.FunctionalCompositeMap but not for Generic.CompositeMap.)

[thofma]

For your original question, I think it is fine to just call the wrapped map object.

What I don't quite understand is if you are encountering problems/inconsistencies in the maps code base that are (a) already there, or (b) show up just because of proposed move of things from Hecke to AbstractAlgebra?

[mjrodgers]

For your original question, I think it is fine to just call the wrapped map object.

What I don't quite understand is if you are encountering problems/inconsistencies in the maps code base that are (a) already there, or (b) show up just because of proposed move of things from Hecke to AbstractAlgebra?

Some of these were I would say already in AA, others were I think there in Hecke (Hecke had very few tests related to this code, for example there was an issue with _is_attribute_storing_type not working but it was never being used or tested anywhere so I only discovered this trying to make the CodeCov bot happy).

I would say these image_fn problems were already there, at least in the sense that this method is only guaranteed by the interface to be defined for subtypes of the abstract FunctionalMap, but was being used in image calculations for wrapped maps that could be any kind of map. This is easy to fix by changing to just call the wrapped map, I think I fixed all of these in my pr.

For the CompositeMap vs FunctionalCompositeMap, I guess it's more grey. There seems to maybe be a (preexisting) inconsistency between the description of the map interface, and the behavior of the compose method:

Of course, a custom map type or class of maps can implement its own composition type and compose function.

This is the case with the FunctionalMap class for example, which caches the Julia function/closure corresponding to the composition of two functional maps. As this cached function needs to be stored inside the composition, a special type is necessary for the composition of two functional maps.

But in actuality this only applies to Generic.FunctionalMap, and I am wondering if it is because the signature Map(FunctionalMap) is a bit ambiguous, it would resolve in the main codebase to Map(D,C,<:FunctionalMap,T), but resolves in the Generic module to Map{D, C, FunctionalMap, AbstractAlgebra.Generic.FunctionalMap}.

So migrating Generic.FunctionalMap to MapFromFunc means that as is, we will never get a Generic.FunctionalCompositeMap again. If there are any advantages at all to having a FunctionalCompositeMap vs a CompositeMap then we would now be missing out on it.

[mjrodgers]

But maybe this (re: CompositeMap) is what we want in the end, Oscar and Hecke and everything upstream only use CompositeMap and never FunctionalCompositeMap. So whether or not this was the original intention, expanding the use of FunctionalCompositeMap would create issues upstream that would need to be addressed.

Overall, the proposed move of the map types was easy, moving the new definition of map_from_func made the types of some things in AA change but adjustments were easy to make. I'm fixing the last tests and the code is basically ready to review on the AA side (the Hecke CI is not running because it needs approval, but I ran some of the tests locally and they seem to be fine).