Re: [sage-devel] Re: questions about option: inplace vs copy
2015-08-22 13:40:51 UTC+2, Johan S. R. Nielsen: > > > About the naming of the copying form versus in-place form, note that matrices currently have e.g. echelon_form/echelonize and hessenberg_form/hessenbergize. Standardisation would > dictate echeloned or echelon_formed? > Maybe echelonize/echelonized, hessenbergize/hessenbergized. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: questions about option: inplace vs copy
On Monday, August 24, 2015 at 2:51:46 AM UTC-4, Jori Mäntysalo wrote: For example if M is an immutable matrix, would it give more speed to have something like M.__mul__(M, immutable=True)? What would be the benefit over M2 = M**2 M2.set_immutable() other than a more cumbersome syntax that requires you to look up the __mul__ docstring to use it? -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: questions about option: inplace vs copy
Is there a convention for functions returning larger objects? For example if M is an immutable matrix, would it give more speed to have something like M.__mul__(M, immutable=True)? -- Jori Mäntysalo
Re: [sage-devel] Re: questions about option: inplace vs copy
On Mon, 24 Aug 2015, Volker Braun wrote: What would be the benefit over M2 = M**2 M2.set_immutable() other than a more cumbersome syntax that requires you to look up the __mul__ docstring to use it? Speed? I don't know, this is a real question. I just thinked about difference between matrices, graphs and posets. For matrices we have the set_immutable() function. Posets are always immutable. Graphs can be made immutable at creation time, and a copy() can return a mutable graph from immutable (or immutable from mutable). Would we gain anything if - for example - cartesian_product() would have a immutable-option? -- Jori Mäntysalo
Re: [sage-devel] Re: questions about option: inplace vs copy
Basically +1 for Volker's suggestion. Vincent's suggestion on the semantics of copy in constructors seem very dangerous: even if my construction of MyNewObject works today, a seemingly unrelated change to either the caller code or MyNewObject tomorrow could completely break things in highly surprising ways. Don't share mutable objects in subtle ways, when it's natural to think about mathematical objects in an immutable way. About the naming of the copying form versus in-place form, note that matrices currently have e.g. echelon_form/echelonize and hessenberg_form/hessenbergize. Standardisation would dictate echeloned or echelon_formed? Best, Johan Volker Braun writes: IMHO both foo(copy=True) and foo(inplace=False) are fugly and best avoided. They are unintuitive and not discoverable. Basically they are patterns for an API that you can only use by constantly looking up the documentation. If possible, methods should act in-place since that is the most versatile (you cannot un-copy, but you can easily make a copy before acting). So that should always be the default. Of course if the object can be immutable then you can't act in-place. Use past tense to name the copying form of the method. E.g. list.sort() vs. sorted(). * The in-place operation is more useful and therefore the list method * The -ed implies copy. In constructors its best to make copies of mutable data and reference immutable data. Just do the right thing, don't trick the user into introducing subtle errors MyNewObject(data_list, copy=False) or unnecessarily waste memory MyNewObject(data_tuple, copy=True). On Friday, August 21, 2015 at 2:08:45 PM UTC-4, vdelecroix wrote: Hello, While looking at #18481, I realized that we have two argument names that have the same purpose: copy and inplace (one being the contrary of the other of course). As it is worth a convention, I am just asking for your preferences: 1. It does not matter 2. Functions should accept both, ie both my_function(copy=True) and my_function(inplace=True) should work 2. inplace is better 3. copy is better 4. we need another argument name 5. ? Best, Vincent -- -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: questions about option: inplace vs copy
IMHO both foo(copy=True) and foo(inplace=False) are fugly and best avoided. They are unintuitive and not discoverable. Basically they are patterns for an API that you can only use by constantly looking up the documentation. If possible, methods should act in-place since that is the most versatile (you cannot un-copy, but you can easily make a copy before acting). So that should always be the default. Of course if the object can be immutable then you can't act in-place. Use past tense to name the copying form of the method. E.g. list.sort() vs. sorted(). * The in-place operation is more useful and therefore the list method * The -ed implies copy. In constructors its best to make copies of mutable data and reference immutable data. Just do the right thing, don't trick the user into introducing subtle errors MyNewObject(data_list, copy=False) or unnecessarily waste memory MyNewObject(data_tuple, copy=True). On Friday, August 21, 2015 at 2:08:45 PM UTC-4, vdelecroix wrote: Hello, While looking at #18481, I realized that we have two argument names that have the same purpose: copy and inplace (one being the contrary of the other of course). As it is worth a convention, I am just asking for your preferences: 1. It does not matter 2. Functions should accept both, ie both my_function(copy=True) and my_function(inplace=True) should work 2. inplace is better 3. copy is better 4. we need another argument name 5. ? Best, Vincent -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: questions about option: inplace vs copy
Hello Vincent, I do actually prefer to keep both with different semantics (so I guess it is answer 5.). - inplace should be used when the object is being modified within a method (i.e. G.cut_me_in_pieces(inplace=True) will modify G) - copy should be used when we want to specify whether or not we want to copy the arguments being used in the function (i.e. MyNewObject(data=[1,2,3], copy=False) then the created oject will hold a reference to the list [1,2,3] given in input) Vincent On 21/08/15 20:08, Vincent Delecroix wrote: Hello, While looking at #18481, I realized that we have two argument names that have the same purpose: copy and inplace (one being the contrary of the other of course). As it is worth a convention, I am just asking for your preferences: 1. It does not matter 2. Functions should accept both, ie both my_function(copy=True) and my_function(inplace=True) should work 2. inplace is better 3. copy is better 4. we need another argument name 5. ? Best, Vincent -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
