SSP Data Defs and Table of Symbols cannot index
I'm creating a new issue that stemmed from #265 being mostly fixed for clarity on what is still an issue.
The way Index works is that it is built into Expr. This works well for most cases except for two.
Data Defs used an index-ed variable as the output such as the example given below. But the QDefinition takes a Quantity s, SymbolForm s and Expr to equate them. This means I cannot index the quantity becuase Index returns an Expr.

The second issue is that I need to remove the subscript i from the symbols otherwise we would get duplicated is when index-ing them. This means the table of symbols displays the symbol without the subscript i.
I'm not sure what the best solution would involve. We could;
- create a new data constructor for
Symbolthat can be a special index which would get ignored byExpr - change the type of
Index - change the type of
QDefinitionand Table of Symbol constructors
Making a note that @AKM11 has a similar issue in NoPCM.
Can't we use some kind of pair as Index, to index by more than one thing "at once"? [This is different than double-indexing].
@JacquesCarette I'm not sure what you mean by "some kind of pair". Do you mean, "Can we index the whole equation, rather than just the individual quantities?"
I mean something that would mean the same as a[i,j], i.e. Index(a, Pair(i,j)) as an Expr. I don't know if we have the Pair constructor (or something like it) in Expr yet.
We do not have something like that in Expr yet. That is not part this issue though. Right now, I'm treating "Ut,i" as "(Ut)i" where Ut is the symbol for the quantity and I am indexing it at i. The issue is that I cannot use Index on the left hand side of a QDefinition because you cannot index a symbol, only an Expr.
I see, that is a rather different issue indeed.
QDefinition really is for defining single values (depending on an arbitrary number of other things, which do not need to be single values). Whether QDefinition can also be used to define vectors, arrays, tables, etc, is quite unclear to me. That will need some design.
This needs to be solved for #397 to be fixed, as half of the current "duplicate" symbols are actually symbols that need to be indexed at some variable.
As I revisit this: the correct fix is to add 'indexing' to Expr. It's a bit of a cheat, since indexing is really not very different from application (vectors, for example, can be seen as functions from [0..n-1] -> Space). But we want to display them differently. And they are typed (slightly) differently. So, for now, adding indexing to Expr is the best way to go about it.
@JacquesCarette I know you looked at this in a lot more depth recently, have you made any headway on how indexing should be handled particularly?
Nope, unfortunately not. I'll push it up on my priority list.