Any help/views/suggestions on the above discussion would be greatly appreciated.
Thanks and regards, Vatsal. On Tue, 10 Mar 2020, 03:13 Vatsal Srivastava, <[email protected]> wrote: > Typo: we *need not* provide the functor the explicit map, but just the > field and the set S. > > On Tue, 10 Mar 2020, 03:11 Vatsal Srivastava, <[email protected]> wrote: > >> But just like you correctly pointed out, the code does not support >> infinite categories. Regardless, why not just have an unevaluated object to >> accommodate for the potentially infinite categories, and a derived class >> for the finite ones? >> The reason why I think the latter is important, is because there are a >> few types of functors which are defined conceptually, for eg: >> >> 1. Linearization Functor: >> This is a functor from the category of sets to the category of vector >> spaces, and is defined as follows: >> >> Fix a field k. To each set X, one can define a vector >> space, denoted kX, whose elements are formal finite >> linear combinations >> a1x1 + a2x2 + · · · + anxn, >> where ai ∈ k and xi ∈ X. >> That clearly maps ever set, to some vector space. >> >> Now to map the morphisms, given a function f : X → Y (where X and Y are >> sets) , define the linear map >> k_f: kX → kY by replacing each xi in a given >> linear combination with f(xi). >> One checks that this mapping of f to k_f indeed preserves the composition >> operation of functions. >> So mapping every set X to a vector space kX, and every function f to a >> linear map k_f, we have ourselves a functor. >> Now, to compute where a given set S would land under this functor, we >> need provide the functor the explicit map, but just the field, and the set >> S. >> >> 2. Forgetful Functor: This is the kind of functor that loses (or >> 'forgets') information about the objects/morphisms. For this too, we just >> need the object in the domain category, and a flag that somehow depicts to >> what extent the information has to be forgotten (possible implementation?) >> >> Also, I was wondering if anybody needs to use the Category Theory module >> for research purposes, etc, they would need all the basic categories >> implemented and the basic functors amongst them right? For eg, sets, >> monoids, rings, groups, algebras etc? So should these be implemented >> separately in the category theory module or integrated with wherever else >> in the code these may have been implemented? >> >> Thanks and regards, >> Vatsal. >> >> On Tue, 10 Mar 2020, 01:54 Aaron Meurer, <[email protected]> wrote: >> >>> I think it would be more useful to represent functors as unevaluated >>> objects. That way, you can manipulate them on abstract category >>> objects, which may actually represent infinite categories. >>> >>> See also this issue https://github.com/sympy/sympy/issues/17964 >>> >>> Aaron Meurer >>> >>> On Sun, Mar 8, 2020 at 6:37 AM Vatsal Srivastava <[email protected]> >>> wrote: >>> > >>> > Hi, >>> > >>> > I've been reading the category theory module, and I found that >>> functors have not been implemented yet. I propose to do this during Phase 1 >>> of the GSoC project. >>> > >>> > I was wondering if we should implement it as simply an object that >>> stores two dicts, one would be a map between objects of two categories, and >>> the other one would be a map between morphisms of the same two categories. >>> These maps would have to be supplied as parameters while creation of the >>> object. >>> > >>> > This class could then have derived classes like one for Linearization >>> Functors, in that case we needn't supply the map or the other category (the >>> codomain), but we would have to supply a field over which the linearization >>> would be done. >>> > >>> > Suggestions are most welcome. >>> > And please tell me if I should include some more work in Phase 1. As >>> soon as I get more idea about how I can implement these, I can propose the >>> work in the remaining phases too. >>> > >>> > Thanks, >>> > Vatsal Srivastava. >>> > >>> > -- >>> > 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/CANr2OynjRj8kMD6GszQwyMd_SyusVONJP5rL2ooCCf9qfKPtZQ%40mail.gmail.com >>> . >>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/CAKgW%3D6LHr7fjcL1K13pamjajxpRF6Dw%3D4DFkT6enV8HrNVUd3Q%40mail.gmail.com >>> . >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CANr2Oykw8Xg3QnDOFU_OtwMNgricxxNnw2-TnsDFBV_0gmEK7A%40mail.gmail.com.
