You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@sglyon: I am starting to like the FunctionFactory object but find it somewhat inconsistent (partly my fault of course.
Here is what we have, for flat arguments (resp group arguments):
It looks to me that some of this content is not useful to write functions and require further processing.
I propose the following simplifications,
1/ all symbols and equations are normalized (in args list and in defs)
2/ params disappears
3/ definitions are preprocessed and stored in the right order so they can be computed sequentially (not clear in the examples above)
4/ incidence is replaced by an incidence table without any notion of time.
The first example would become (only the changing fields):
I see a few advantages to this change:
1/ it allows to experiment much more easily with other types of function generation (a basic function is super easy to write, since one just needs to list all definitions, then all equations (and unpack/pack the argument vectors)
2/ it is quite indifferent to where the normalized symbols come from. They can be simple timed variables or come from more complex indexing schemes ( :_∂x_i_∂y_j )
I don't see any disadvantage.
For "flat arguments" (the distinction kind of disappears), we can define f(x,p), f(Der{1}, x, p), f(Der{2}, x, p), with the convention that first argument is the one that get differentiated. So f(Der{2}, x, y, p), would be ∂2f/∂y2. This would of course work if there are no definitions or after they are substituted in the other equations.
For "grouped arguments" we could have selective differentiation like f(Der{0,:x,:z}, x,y,z,p) which would return f,∂f/∂x,∂f/∂z.
To smooth the transition, we could have both object coexist. @sglyon : what do you think ?
The text was updated successfully, but these errors were encountered:
Hey @albop thanks for taking the time to write this up.
I think it would be very nice to refactor the FunctionFactory code -- much of what was contained in there is a remnant from a time when I did things like equation verification using an instance of the type. Given that this is no longer done, we can definitely clean some things out.
I don't have the energy to carefully review the proposal right now and will be traveling tomorrow, but will try to find time soon to give a more thoughtful response. If I don't respond in the next couple of days, please remind me and I will make it happen.
@sglyon: I am starting to like the FunctionFactory object but find it somewhat inconsistent (partly my fault of course.
Here is what we have, for flat arguments (resp group arguments):
(resp.
)
It looks to me that some of this content is not useful to write functions and require further processing.
I propose the following simplifications,
1/ all symbols and equations are normalized (in args list and in defs)
2/
params
disappears3/ definitions are preprocessed and stored in the right order so they can be computed sequentially (not clear in the examples above)
4/ incidence is replaced by an incidence table without any notion of time.
The first example would become (only the changing fields):
and the second one:
I see a few advantages to this change:
1/ it allows to experiment much more easily with other types of function generation (a basic function is super easy to write, since one just needs to list all definitions, then all equations (and unpack/pack the argument vectors)
2/ it is quite indifferent to where the normalized symbols come from. They can be simple timed variables or come from more complex indexing schemes ( :_∂x_i_∂y_j )
I don't see any disadvantage.
f(x,p)
,f(Der{1}, x, p)
,f(Der{2}, x, p)
, with the convention that first argument is the one that get differentiated. Sof(Der{2}, x, y, p)
, would be∂2f/∂y2
. This would of course work if there are no definitions or after they are substituted in the other equations.f(Der{0,:x,:z}, x,y,z,p)
which would returnf,∂f/∂x,∂f/∂z
.To smooth the transition, we could have both object coexist.
@sglyon : what do you think ?
The text was updated successfully, but these errors were encountered: