updated with tk plot

Author: schochastics

revdep/examples/README.md

@@ -32,6 +32,13 @@ Each issue has two files:
 #### Group E — Indirect path through a defunct fallback
 12. **degreenet-reedmolloy-issue** — defunct `sample_degseq(method = "simple.no.multiple")` fallback inside `reedmolloy()`'s retry loop
 
+#### Group F — `tkplot()` defunct (igraph 3.0.0)
+13. **tkplot-defunct-issue** — shared reproducer for Boptbd, c3net, ggm, optbdmaeAT, optrcdmaeAT (all direct callers of `igraph::tkplot()`)
+
+#### Group G — API tightening / behavioural changes
+14. **jewel-integer-issue** — strict integer validation in `rewire_impl()`
+15. **rspectral-modularity-issue** — `modularity()` auto-uses `"weight"` edge attribute
+
 Three packages from the failure set (dci, ggraph, scistreer) are pure cascades through tidygraph and have no separate reproducer — see `tidygraph-bfs-father-issue` for the root cause.
 
 ## Running the Examples
@@ -77,5 +84,12 @@ The examples follow a simplified format:
 | R6causal | Install-time deprecation warnings | Medium | Pre-emptive rename needed |
 | migraph | `create_ring(width=)` warning → test failure | Low | Deprecated argument |
 | degreenet | Defunct fallback `sample_degseq(method=)` value | High | Defunct argument value (indirect) |
+| Boptbd | `tkplot()` defunct | High | Removed function (PR #2615) |
+| c3net | `tkplot()` defunct | High | Removed function (PR #2615) |
+| ggm | `tkplot()` defunct | High | Removed function (PR #2615) |
+| optbdmaeAT | `tkplot()` defunct | High | Removed function (PR #2615) |
+| optrcdmaeAT | `tkplot()` defunct | High | Removed function (PR #2615) |
+| jewel | Strict integer validation in `rewire_impl()` | High | API tightening |
+| rSpectral | `modularity()` auto-uses `"weight"` | Medium | Behavioural change (needs igraph opt-out) |
 
 See [`../problems-analysis.md`](../problems-analysis.md) for detailed analysis and recommendations.

revdep/examples/jewel-integer-issue.R

@@ -0,0 +1,39 @@
+# jewel non-integer rewire iteration count
+# Issue: jewel computes niter = p * 0.05 (fractional) and passes it through
+# igraph::rewire(), whose C interface now strictly rejects non-integer values.
+
+library(igraph)
+
+g <- make_ring(20)
+
+# Old call pattern -- niter ends up fractional
+p <- 49
+niter_bad <- p * 0.05    # 2.45
+
+# rewire(g, with = keeping_degseq(niter = niter_bad))
+# Error in rewire_impl(rewire = graph, n = niter, mode = mode) :
+#   The value 2.45 is not representable as an integer. Invalid value
+# Source: rinterface_extra.c:83
+
+# Working replacement -- round to an integer up front
+niter <- as.integer(ceiling(p * 0.05))
+res <- rewire(g, with = keeping_degseq(niter = niter))
+ecount(res)
+
+# Root cause:
+# - igraph's C interface now strictly validates that numeric arguments are
+#   exactly representable as integers. Fractional values were previously
+#   truncated silently.
+# - jewel:::generateData_rewire() ultimately calls rewire() with
+#   `niter = p * 0.05`, which is non-integer for many p.
+
+# Assessment:
+# - Bug in jewel -- a count of iterations should always be an integer.
+
+# Recommendation:
+# - For jewel: integer-round the value before the rewire() call, e.g.
+#     niter <- as.integer(ceiling(p * 0.05))
+#   (or floor(), or round() -- whichever matches the intended semantics).
+# - For igraph (optional defensive measure): consider adding as.integer()
+#   on the R side in rewire_keeping_degseq() before calling rewire_impl().
+#   The strict C-side check is the correct contract.

revdep/examples/jewel-integer-issue.md

@@ -0,0 +1,37 @@
+# jewel non-integer rewire iteration count
+
+## Issue
+```
+Error in rewire_impl(rewire = graph, n = niter, mode = mode) :
+  The value 2.4500000000000002 is not representable as an integer. Invalid value
+Source: rinterface_extra.c:83
+```
+
+`jewel:::generateData_rewire()` computes `niter = p * 0.05` (often fractional) and passes it through `igraph::rewire()`, whose C interface now strictly rejects non-integer values.
+
+## Reproducible Example
+
+```r
+library(igraph)
+g <- make_ring(20)
+p <- 49
+niter_bad <- p * 0.05    # 2.45
+
+rewire(g, with = keeping_degseq(niter = niter_bad))
+#> Error in rewire_impl(rewire = graph, n = niter, mode = mode) :
+#>   The value 2.45 is not representable as an integer. Invalid value
+
+# Working replacement
+rewire(g, with = keeping_degseq(niter = as.integer(ceiling(p * 0.05))))
+```
+
+## Root Cause
+igraph's C interface now strictly validates that numeric arguments are exactly representable as integers. Previously, fractional values were silently truncated.
+
+## Assessment
+Bug in jewel — a count of iterations should always be an integer.
+
+## Recommendation
+**For jewel**: integer-round the value before the `rewire()` call: `niter <- as.integer(ceiling(p * 0.05))` (or `floor()`, or `round()` — pick the one that matches intended semantics).
+
+**For igraph** (optional defensive measure): consider adding `as.integer()` on the R side in `rewire_keeping_degseq()` before calling `rewire_impl()`. The strict C-side check is the correct contract, but the R wrapper could be friendlier.

revdep/examples/rspectral-modularity-issue.R

@@ -0,0 +1,51 @@
+# rSpectral modularity() now auto-uses the "weight" edge attribute
+# Issue: rSpectral's stored test graphs carry a "weight" attribute. Previously
+# modularity() ignored it unless weights = E(g)$weight was passed explicitly;
+# now modularity() auto-detects and uses the attribute, changing the computed
+# values and breaking baseline assertions.
+
+library(igraph)
+
+# A small graph with a weight attribute
+g <- make_ring(5)
+E(g)$weight <- c(1, 2, 3, 4, 5)
+
+# Same membership, two different modularity calls
+membership <- c(1, 1, 2, 2, 2)
+
+# Old behaviour (ignored weights unless passed explicitly):
+# the value below is what modularity() returned before the change
+modularity(g, membership, weights = rep(1, ecount(g)))
+
+# New behaviour (auto-detects $weight):
+modularity(g, membership)
+
+# These two now differ -- which is exactly what breaks rSpectral's tests.
+
+# Root cause:
+# - Around igraph 2.2.1.9004, modularity() was changed to use the "weight"
+#   edge attribute automatically when present:
+#     if (is.null(weights) && "weight" %in% edge_attr_names(graph)) {
+#       weights <- E(graph)$weight
+#     }
+# - rSpectral's stored test graphs carry a "weight" attribute that was not
+#   intended to be consumed by modularity().
+
+# Assessment:
+# - Behavioural change in igraph. Inadvertent semantics shift for callers
+#   that did not intend to use weights. There is currently no clean
+#   `weights = NA` opt-out.
+
+# Recommendation:
+# - For igraph (action required before notifying rSpectral): provide a clean
+#   opt-out -- e.g. accept `weights = NA` to disable auto-detection -- and
+#   document the contract change in NEWS.md.
+# - For rSpectral (once an opt-out exists, or after igraph adjusts):
+#     1. Determine whether the stored graphs were intended to carry $weight.
+#     2. If not: g <- igraph::delete_edge_attr(g, "weight") before modularity()
+#        and run igraph::upgrade_graph() on stored graph objects.
+#     3. If yes: update the expected modularity baselines.
+
+# Workaround that happens to disable auto-detection today (DO NOT recommend
+# to downstream maintainers -- relies on implementation detail):
+#   modularity(g, membership, weights = numeric())

revdep/examples/rspectral-modularity-issue.md

@@ -0,0 +1,52 @@
+# rSpectral modularity() now auto-uses the "weight" edge attribute
+
+## Issue
+Two test failures: modularity values diverge from the expected baselines.
+
+```
+── Failure ('test-igraph.R:19:3'): membership fix_neig=0 is correct ────────────
+Expected `c$modularity` to equal `exp_mod10`.
+  `actual`: 0.432
+`expected`: 0.408
+
+── Failure ('test-igraph.R:26:3'): membership fix_neig=1 is correct ────────────
+  `actual`: 0.3758
+`expected`: 0.3776
+```
+
+## Reproducible Example
+
+```r
+library(igraph)
+g <- make_ring(5)
+E(g)$weight <- c(1, 2, 3, 4, 5)
+membership <- c(1, 1, 2, 2, 2)
+
+# Old behaviour (ignored $weight unless passed explicitly)
+modularity(g, membership, weights = rep(1, ecount(g)))
+# New behaviour (auto-detects $weight)
+modularity(g, membership)
+# The two now differ.
+```
+
+## Root Cause
+Around igraph 2.2.1.9004, `modularity()` was changed to use the `"weight"` edge attribute automatically when present:
+```r
+if (is.null(weights) && "weight" %in% edge_attr_names(graph)) {
+  weights <- E(graph)$weight
+}
+```
+rSpectral's stored test graphs carry a `"weight"` attribute that was not intended to be consumed by `modularity()`.
+
+## Assessment
+Behavioural change in igraph. Inadvertent semantics shift for callers that did not intend to use weights. No clean `weights = NA` opt-out currently exists.
+
+## Recommendation
+**For igraph** (action required before notifying rSpectral): provide a clean opt-out — e.g. accept `weights = NA` to disable auto-detection — and document the contract change in `NEWS.md`.
+
+**For rSpectral** (once an opt-out exists, or after igraph adjusts):
+1. Determine whether the stored graphs were intended to carry `$weight`.
+2. If not: `g <- igraph::delete_edge_attr(g, "weight")` before `modularity()`, and run `igraph::upgrade_graph()` on the stored graph objects.
+3. If yes: update the expected modularity baselines.
+
+A hacky workaround that happens to disable auto-detection today is `modularity(g, membership, weights = numeric())`, but this relies on internal implementation detail and **must not** be recommended to downstream maintainers.

revdep/examples/tkplot-defunct-issue.R

@@ -0,0 +1,36 @@
+# tkplot() defunct (igraph 3.0.0)
+# Issue: tkplot() advanced to deprecate_stop in #2615. Five revdep packages
+# call it directly from their examples:
+#   Boptbd::graphoptBbd()
+#   c3net::netplot() (used by c3net::c3net(..., network = TRUE))
+#   ggm::AG(..., plot = TRUE)
+#   optbdmaeAT::graphoptbd.mae()
+#   optrcdmaeAT::graphoptrcd.mae()
+
+library(igraph)
+
+g <- make_ring(5)
+
+# Old call -- now defunct in igraph 3.0.0
+# tkplot(g)
+# Error:
+# ! `tkplot()` was deprecated in igraph 3.0.0 and is now defunct.
+
+# Working replacement -- non-interactive plot
+plot(g)
+
+# Root cause:
+# - The interactive Tk-based plotter has been removed; non-interactive plot()
+#   is the recommended drop-in replacement.
+# - All five affected packages are direct callers.
+
+# Assessment:
+# - Intentional removal in igraph (#2615).
+
+# Recommendation:
+# - For each affected package: replace igraph::tkplot(g, ...) with
+#   igraph::plot.igraph(g, ...) (or just plot(g, ...)).
+# - Tk-specific tuning functions (tkplot.canvas, tkplot.setcoords, ...) are
+#   themselves deprecated and have no direct replacement. Packages that
+#   genuinely needed interactive editing should adopt a JS-based plotter
+#   (e.g. visNetwork) instead.

revdep/examples/tkplot-defunct-issue.md

@@ -0,0 +1,37 @@
+# tkplot() defunct (igraph 3.0.0)
+
+## Issue
+`igraph::tkplot()` advanced to `deprecate_stop("3.0.0", "tkplot()")` in [#2615](https://github.com/igraph/rigraph/pull/2615). Five revdep packages call it directly from their examples and now hard-error with the same message.
+
+| Package | Caller |
+|---|---|
+| Boptbd | `Boptbd::graphoptBbd()` |
+| c3net | `c3net::netplot()` (via `c3net::c3net(..., network = TRUE)`) |
+| ggm | `ggm::AG(..., plot = TRUE)` |
+| optbdmaeAT | `optbdmaeAT::graphoptbd.mae()` |
+| optrcdmaeAT | `optrcdmaeAT::graphoptrcd.mae()` |
+
+## Reproducible Example
+
+```r
+library(igraph)
+g <- make_ring(5)
+
+tkplot(g)
+#> Error:
+#> ! `tkplot()` was deprecated in igraph 3.0.0 and is now defunct.
+
+# Working replacement
+plot(g)
+```
+
+## Root Cause
+The interactive Tk-based plotter has been removed. Non-interactive `plot()` (i.e. `plot.igraph()`) is the recommended drop-in replacement.
+
+## Assessment
+Intentional removal in igraph (#2615). All five packages are direct callers; no cascading.
+
+## Recommendation
+**For each affected package**: replace `igraph::tkplot(g, ...)` with `igraph::plot.igraph(g, ...)` (or just `plot(g, ...)`).
+
+Tk-specific tuning functions (`tkplot.canvas`, `tkplot.setcoords`, …) are themselves deprecated and have no direct replacement. Packages that genuinely needed interactive graph editing should adopt a JS-based plotter (e.g. `visNetwork`) instead.