missing "isSB" attribute for output of Singular.std?

[YueRen]

I am trying to use triangL, but it returns an error that the input is not a Groebner basis even though it is the output of Singular.std:

julia> R,(x,y) = GF(101)["x","y"]
(Multivariate polynomial ring in 2 variables over K, FqMPolyRingElem[x, y])

julia> I = ideal([x,y])
Ideal generated by
  x
  y

julia> Singular.LibTriang.triangL(Singular.std(Oscar.singular_generators(I)))
ERROR: The input is no groebner basis.
leaving triang.lib::triangL (0)

Stacktrace:
 [1] call_singular_library_procedure(arg1::String, arg2::CxxWrap.CxxWrapCore.CxxPtr{…}, arg3::Vector{…})
   @ Singular.libSingular ~/.julia/packages/CxxWrap/eWADG/src/CxxWrap.jl:668
 [2] low_level_caller(lib::String, name::String, args::Singular.sideal{Singular.spoly{Singular.n_Zp}})
   @ Singular ~/.julia/packages/Singular/y9hxp/src/caller.jl:399
 [3] triangL(args::Singular.sideal{Singular.spoly{Singular.n_Zp}})
   @ Singular.LibTriang ~/.julia/packages/Singular/y9hxp/src/Meta.jl:44
 [4] top-level scope
   @ REPL[75]:1
Some type information was truncated. Use `show(err)` to see complete types.

In Singular.jl, whether an ideal is known to be a Groebner basis is stored in a flag isGB:

julia> Isingular = Oscar.singular_groebner_generators(I)
Singular ideal over Singular polynomial ring (ZZ/101),(x,y),(dp(2),C) with generators (y, x)

julia> Isingular.isGB
true

While in Singular, it is stored in an attribute "isSB":
https://github.com/Singular/Singular/blob/9ef276812c797530d569a8b4e60f0caa23dc0443/Singular/LIB/triang.lib#L38

Could it be that they do not interact with each other?

[hannes14]

Yes, all Singular attributes are ignored by the conversion from Singular to Singular.jl, and none are set by the conversion in the other direction.
It is difficult to add this attribute to the conversion as only the type (an int) and the pure date (a void*) are passed to Singular
and only within Singular the argument list for library calss (which may contain attributers) are created

[YueRen]

That sounds like a difficult issue to solve.

For now, I guess I can use Singular.call_interpreter like I've done in
https://github.com/oscar-system/Oscar.jl/blob/c343528773c099ca00ab6a6e50883a586f203017/src/TropicalGeometry/variety_prime.jl#L44-L49

But I'm not sure whether that is a good long-term solution.

[ederc]

Does this mean that any Singular lib function which assumes, for example, a GB as input, is not (or only with some tricks we should not rely on) usable from Singular.jl resp. Oscar?

[YueRen]

Yes, seems like it. I think the options are

(a) provide Singular library functions that don't require a GB input and use those from Oscar instead:

proc triangLAndGroebner(ideal I)
{
  return(triangL(groebner(I)))
}

(b) change user-facing functions like triangL to compute the GB instead of returning an error.

proc triangLAndGroebner(ideal I)
{
  if (attrib(G,"isSB") <> 1)
  {
    G = groebner(G);
  }
  [...]
}

[YueRen]

A quick grep if.*isSB *.lib only shows 72 hits, and the vast majority are hits like

    if(!attrib(assprimes[i], "isSB"))
    {
      assprimes[i] = modStd(assprimes[i], exactness);
    }

So we're not talking about that many functions.

[ederc]

(c) Rewrite this Singular lib code in Oscar.

[YueRen]

I've just went through the list, the only functions that raise an error if not given a Groebner basis are:

1. truncateFast in sheafcoh.lib
2. triangL in triang.lib
3. triangLbas in triang.lib
4. triangM in triang.lib
5. triangMH in triang.lib

I am in favor of changing them to compute a Groebner basis instead.

[ederc]

A quick grep if.*isSB *.lib only shows 72 hits, and the vast majority are hits like

    if(!attrib(assprimes[i], "isSB"))
    {
      assprimes[i] = modStd(assprimes[i], exactness);
    }

So we're not talking about that many functions.

But there may be other attributes.