Avoid the Gaussian-only road

[Affie]

i think we should solve @GearsAD ‘s concerns regarding softtype on CG first before we close this? I’m happy with name only if it solves the right problem. I’m worried about the CG stuff going down a Gaussian-only road and end up forcing the overall DFG side to a crisp but overly restrictive DataLevel1 space. I mean that users just want Level1 and moan it’s not working well enough, and somehow get out of using Level2. To help avoid all that i think softtypename::Symbol/String is good.

Just to reiterate, i originally wanted to avoid duplication of the whole softtype so just guessed name as a string as cheap hack. Without the necessary type information for non-Julia use cases, i’m not sure... Again the question for me is what do we want from Summary (what is the one sentence existence proof for Summary/Level1?).

Is it fair for a user to avoid the Julia internals just to get the inference product in a usable way, or should they at least don some of the Julia-ness to use the inference products? Perhaps i should add, (again) that we are not building Gaussian-only, so the user should get the full beliefs, not just hide behind PPE. That means DataLevel2. I don’t want to dumb down the output and look shoddy against a more mature Gaussian-only system. I’d rather force the user into Julia or build a better multilang interface (I vote the latter).

I know Neo4j has a bunch of nice features for Gaussian-only, but that should be “supportive” not “authoritative” in the design.

I would argue Summary/Level1 CANNOT be it is the final inference product. The final inference product is and always should be DataLevel2.

TL;DR I fairly strongly feel softtypename as Symbol/String or remove completely from Level1. If there are cool features in Neo4j we can leverage, then leave that door open; but the DB should not dictate our design too much but rather store what is needed — pattern here is strongly non-Gaussian (ie not just PPE).

Originally posted by @dehann in #237 (comment)

[Affie]

I made it into a separate issue as it was raised on several occasions and discussions.

[GearsAD]

I know Neo4j has a bunch of nice features for Gaussian-only, but that should be “supportive” not “authoritative” in the design.

I understand the concern, although I think this is welding two issues together again:

• Neo4j isn't opinionated about datatypes (ref: Gaussian-only), but there are spatial types that are available and would support efficient searching. If we use these (as I'm advocating) then we are using the data-layer far more efficiently. More to follow on this in a few months. I support saving all the data using this, so that we can pull back the beliefs too.
• Softtype issue is related but not the same? We want to be able to reference a variable's 'schema' so we know what to plot, or at least how to introspect it.

[Affie]

I just referenced the whole comment here with the idea that it is only about the Gaussian only issue that Dehann really wants to make clear.

Neo4j isn't opinionated about datatypes (ref: Gaussian-only), but there are spatial types that are available and would support efficient searching. If we use these (as I'm advocating) then we are using the data-layer far more efficiently. More to follow on this in a few months. I support saving all the data using this, so that we can pull back the beliefs too.

I'm for this. To efficiently search for point close to somewhere is awesome. We can make that less "Gaussian only" by including all beliefs and approximate covariances somehow.

[GearsAD]

Yeah, I really like the idea of dumping the whole belief in the same way, that would be really great for visualization

[dehann]

would support efficient searching.

To efficiently search for point close to somewhere is awesome.

I support this too!

the idea that it is only about the Gaussian only issue that Dehann really wants to make clear

Pretty much yeah, this is to keep everybody aligned. Our strength will be in the balance between using parametric stuff that exists, and clearing the way for everybody else to use non-Gaussian stuff. I'm happy if you guys are happy.