solved or count if no statelabel

[dehann]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.21%. Comparing base (8909fee) to head (98c8dbe).

Files with missing lines	Patch %	Lines
src/services/variable_ops.jl	66.66%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1255      +/-   ##
===========================================
- Coverage    81.25%   81.21%   -0.05%     
===========================================
  Files           50       50              
  Lines         2700     2704       +4     
===========================================
+ Hits          2194     2196       +2     
- Misses         506      508       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Affie]

My pattern here was that it follows the rest of DFG where you get an error if you ask for a node that does not exist. As an example, it is the same pattern if you ask for a state on a variable that does not exist you get an error that the variable does not exist.

[dehann]

okay, but how then do we solve this problem:

fg = initfg()

addVariable!(fg, :x0, Position1)

isSolved(fg, :x0)
isIinitialized(fg, :x0)
solveCount(fg, :x0)

I think am convinced returning an error for any of these cases is wrong. They should all just return false or 0, no?

[dehann]

Remember a user has no idea what stateLabel is/means at this point. Also, basic usage should not have any friction related to other super-duper features power users need later.

[dehann]

maybe the verb is wrong, i.e.:

listSolved
listInitialized

[dehann]

There still is need for a default stateLabel everywhere -- something like isSolved(fg, :x0; stateLabel = :canverify) vs stateLabel = :navabilityVerified (if commercial need exists). Some effort required on picking the right names here

[Affie]

I don’t know yet. The pattern for getState is to explicitly require a state label, so isSolved(fg, :x1, :default) should return an error if default is not found.
Can a variable be solved or only the state? I would lean towards isSolved without the state label to be more like a list solved, that list the solved states.
But this wasn’t planned as a stable function for dfg v1. So we can still change and finalise in v1.x.

[Affie]

maybe the verb is wrong

I agree. The get verb should have a consistent signature and behaviour.

[Affie]

The submersion is a map and has to be explicitly provided. This example of 2 e1 = [1, 0, 0] "partials" shows why:

• f(R) = vee(log(R))ᵀ * e₁ # SO(3) -> ℝ¹
• f(R) = R * e₁ # SO(3) -> S²

[Affie]

Note: All functions with deprecated solveKey name is not DFG v1 ready yet and un-exported.

Looking at this again, the verb and noun are both incorrect.

• the noun should match the field name solves
• for the verb we discussed tally: Calculates value of countable field (ex. number of solves completed)

[Affie]

tallySolves(v::VariableDFG) should still count the solves across all states though, so no default state_label.

[Affie]

I would use the direct field access here as discussed (TODO find ref).

For a list alternative we have listStates and can add a whereSolves filter, ie. whereSolves = >(0).

[Affie]

Since these functions were deprecated and is not exported, we can probably change the behaviour as in the pr without bumping the minor to v0.30.
We can then resolve my 2 comments in v1.x.

[Affie]

There still is need for a default stateLabel everywhere...

Maybe in higher level helpers, but not in the core API (like get). Dropping the previous solveKey default from the now named getState, exposed a handful of bugs, some quite serious where :defaut was implicitly used instead of the requested solveKey.

[dehann]

So we can still change and finalise in v1.x.

We should not merge PR in current state, rather update. Just need to update the IIF tests which depend on these functions.

But this wasn’t planned as a stable function for dfg v1.

So the solution to the example above becomes?

fg = initfg()

addVariable!(fg, :x1, Position1)

@assert !any(listStates(fg)) "nothing should have been solved yet"
@assert 0 === tallyStatesfg) "nothing should have been solved yet"

tally vs Solves vs States

I'm getting a bit confused in the cross between verb and Noun here.

• solve vs Solves vs States
• the where filter seems odd whereSolves.
• Also, whereTally doesn't seem to work either.
• tallySolves works, but tallyStates seems better?
  • Maybe whereStates?

Do we have a Noun Definition for Solves? I'm expecting verb solve is one way to produces a State.

I would use the direct field access here as discussed (TODO find ref).

Uhmm, I don't fully remember the detail, do we have that captured in a thread somewhere? Do you mean that non-exported features of DFG v1.0 should temporarily be accessed via ref until we resolve exported API in v1.x?

[Affie]

Uhmm, I don't fully remember the detail, do we have that captured in a thread somewhere? Do you mean that non-exported features of DFG v1.0 should temporarily be accessed via ref until we resolve exported API in v1.x?

At some stage we discussed how to handle cross platform/language api vs julia field mutations/access, we said we should use the .fieldname notation, as in state.solves += 1. This was to make it very clear that if you mutate a field in this way it will not update in the cloud. (I think it is relevant here as well)

DF EDIT: use ref for in-memory access only (avoids remote queries or mutations).

[Affie]

Do we have a Noun Definition for Solves?

yes, see Nouns (from ICRA)
Integer value indicating the number of solves that have been done on a specific state label

[Affie]

whereSolves is correct for the noun Solves.

listStates(v, whereSolves = >(0))
Read it as "list all states in variable v where solves > 0."

[dehann]

okay, so I think the definition piece I'm getting tripped up on is:
The total retained outcomes from a solve action is stored in both Solves and State, where only the solve action can increment Solves but with the reminder that State may be populated from other non-solve action sources.