Add flags and metadata

[jlperla]

Right now you have a single subtype::Symbol to differentiate types of variables. Since it is a Symbol it seems very generic, but it also means you can only categorise by one type.

I would like to be able to put in multiple levels of categorization given information known at compile-time. Could either the subtype be extended to support a named tuple of symbols, or could there be an additional flags which allows a set of Symbol flags (also preferably as a named tuple).

[ChrisRackauckas]

I would like to be able to put in multiple levels of categorization given information known at compile-time. Could either the subtype be extended to support a named tuple of symbols, or could there be an additional flags which allows a set of Symbol flags (also preferably as a named tuple).

No, why do you want so much compile-time information in there? That would be very bad for performance. We want to leave subtype strictly typed since it'll be touched in many different ways so it needs to be performant. However, adding an untyped flag field for some extra pieces might be useful (which are distinct from value). It just hasn't been added since it hasn't been needed yet. Feel free to add it in a PR where you need it for some functionality.

[jlperla]

The question is whether you are trying to put in enough flexibility to allow people to experiment with the library without modifying it (and potentially breaking other users). I understand your approach to leave all features until you need them... it is a consistent approach as long as you know how you would design it later.

I am not about to go and design a DSGE model anytime soon, but if the interface doesn't support having a 2nd level of categorization (where totally different code would be generated based on it) then it wouldn't work for that application. The classic example is the categorization of variables into predetermined or not. You organize matrices in very different ways, check different eigenvalues, etc. If you are curious, you can see this in http://www.wouterdenhaan.com/numerical/BKconditionsslides.pdf

For my immediate needs in solving continuous time methods, I am not sure I need it.

Whether that needs to be available at compile-time is a design question for you. I come from a C++ TMP mindset where you almost always want type-safe compile-time information if possible in order to generate specialized algorithms, but maybe that is the wrong approach in Julia.

[ChrisRackauckas]

Whether that needs to be available at compile-time is a design question for you. I come from a C++ TMP mindset where you almost always want type-safe compile-time information if possible in order to generate specialized algorithms, but maybe that is the wrong approach in Julia.

Well the issue here is that this isn't really "Julia" proper. If you want to be technical, it's an IR written in Julia, which uses Julia as the compiler. Essentially this is a human-readable compiler language for scientific computing models. I would never write Julia code like this, but the Julia code it produces is type-stable which is what matters for performance. This kind of code pretty much will not be fully inferrable given the transformations it's doing, but it's not the code that any solvers will see since it will have to pass through the compilation process. I hope that explains why this throws out all of the "Julia best practices".

That said,

I am not about to go and design a DSGE model anytime soon, but if the interface doesn't support having a 2nd level of categorization (where totally different code would be generated based on it) then it wouldn't work for that application. The classic example is the categorization of variables into predetermined or not. You organize matrices in very different ways, check different eigenvalues, etc. If you are curious, you can see this in http://www.wouterdenhaan.com/numerical/BKconditionsslides.pdf

If you need it, then we can add it. It would just be an untyped field which by default gets a nothing, but you can put whatever struct you want in there. I can't think of a better data structure, since forcing an untyped NamedTuple is odd since that won't infer anyways, while a Vector{Pair{Symbol,Any}} would give weird promotion issues all the time.

[ChrisRackauckas]

647ba72