Hey Nicolas,

>  - Would anyone object to making from_* private (i.e. _from_*) since they 
> >  are internal helper functions? 
>
> I do :-) Those are also meant to be called directly by the developer 
> when speed matters. Although arguably one would possibly want: 
>
>         sage: Partitions().from_blah(blah) 
>
> rather than 
>
>         sage: Partition.from_blah(blah) 
>

   Each of these functions (before this patch), at the end, made a call 
back to Partition() (in particular for the stripping of zeros). So I think 
would be better to make each of these functions return an element of the 
partition class (since we're moving the zero stripping into the 
__init__()method). 

   On a further look, I'm wondering if we should inline these functions 
(unfortunately in python this means we have to put the code in place of the 
function call, so we loose some readability :-/ but good comments can make 
up for some of that) since they are only called in Partition() and parsing 
the input arguments is very quick. Thoughts?

I also think Partitions().from_blah(blah) is how we should access these 
functions.

>    Well, this makes it trickier:) An option is one possibility. Speed is 
> a 
> >    consideration (Meinolf Geck told me that he didn't use sage for his 
> python 
> >    Hecke algebra package because it was too slow...), so perhaps this is 
> not 
> >    worth the effort? I think that it is more elegant to use the class, 
> rather 
> >    than a function, as the entry point but not if this creates 
> significant 
> >    extra overhead... 
>
> I agree that speed is a consideration. Now, If I recall correctly, 
> Meinholf main speed issue was elsewhere (with the matrix 
> constructor?), and during his talk I had shown how to work around 
> this until the matrix constructor get optimized. 
>
> >      More general question (to everyone), how should we handle the 
> >      Partition() factory function (for lack of a better term)? Here's 
> kind of 
> >      my questions at present: 
> >      - Should we have an optional parent parameter? 
>
> That should be eventually be handled by the factory infrastructure 
> which fixes conventions on how element class and parent are to be 
> passed down. Maybe you just want to leave things as they are for now 
> until factories come in. 
>

For now I think I will just use Andrew's method since I believe that is a 
step in the direction we plan to take (correct?).

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sage-combinat-devel/-/Lr-8zWH_BewJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.

Reply via email to