On Wed, Mar 22, 2017 at 9:36 AM, Francesco Bonazzi
<[email protected]> wrote:
>
>
> On Tuesday, 21 March 2017 18:30:46 UTC+1, Aaron Meurer wrote:
>>
>> I like the idea, although we've have to make sure to keep things fast,
>> especially for common objects.
>
>
> Yes, that's the main problem. A simple idea is to load these preprocessors
> only if the submodules requiring them are loaded. That way, if someone needs
> a fast code, he should just not to load those submodules.
The independent submodules should definitely register their own
preprocessors in their own code (it would be bad to have units related
code in the core anyway).
But the way I suggested below, the units preprocessor is never called
unless a Unit object is found. So it doesn't affect the performance
for expressions without Units.
>
>>
>> Maybe each class could have a registry, and at the top of each class,
>> it could have a function that checks each argument against the
>> registry. So for instance, for Add:
>>
>> class Add:
>> preprocess_functions = {}
>> @classmethod
>> def flatten(cls, seq):
>> for i in seq:
>> if type(i) in cls.preprocess_functions: # really should
>> check for subclass
>> return cls(*cls.preprocess_functions(seq))
>>
>
> This would apply the preprocess functions many times if the types are
> repeated.
It should probably collect all matching types, and call
cls.preprocess_functions(matching_terms, rest)
Although keep in mind that for objects created with the + operator,
there will always be two arguments to Add. You only get more arguments
when Add is used (e.g., when a routine rebuilds an object).
>
> Is there a way to trigger the preprocessing functions starting from the
> operator?
> That is, if you have something like
>
> 3+y+A+x
>
> and A requires the trigger, one could add a dynamic collection. That is,
> given the evaluation order:
>
> (((3+y)+A)+x)
>
> The second + operator could detect the presence of required triggers in A,
> collect them and then apply them when Add(3, y, A, x) is called.
The Add(3 + y, A) call has no way of knowing that there is another +
that will be applied to it. However, perhaps some efficiency could be
done by passing the new argument x separately.
>
>> Then the units would register Add.preprocess_functions[Unit] =
>> <function that checks unit consistency>.
>
>
> I would use a set rather than a dict.
How would it work as a set? How do you know which function to call?
>
>>
>>
>> There are a lot of details to work out here, but is that the basic
>> idea you are suggesting?
>
>
> Yes, approximately. Maybe it can be further improved by thinking a bit more.
>
> We could experiment with the new unitsystem module as soon as I finish its
> refactoring.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/468ab060-a073-4684-ad10-db4b0b4fca94%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6K2J_PGZMdmG6QXPquQYg7JangLHsMAeen%3DZpg5JDa8xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
