@ Christopher, I completely agree that constructing temporary sets from lists adds the overhead. I was only going off your own code example where you already convert your dag iterator into a list: list(iterator), vs doing set(iterator). Sets do have a slightly higher cost for construction. But again, following my "first thought" mentality, I would have probably figured that the loop and membership test is the focus and not the construction. Again, I also completely agree that readability counts. But if just doing s/list/set/ improves time complexity without sacrificing readability, I tend to commit that to my "first thought" muscle memory.
@ Joe, ya that's actually what I like about allowing threads to slightly go off-topic on this list. It tends to bring out pretty useful discussions. Maybe other lists are pretty adamant about keeping each thread on topic, and generally it would be a good idea. But at least this side discussion wasn't completely off topic, as it was discussing extra code that was presented as an example for the original topic. It all adds up anyways to a pretty informative archive. On Wed Dec 03 2014 at 05:52:50 Joe Weidenbach <[email protected]> wrote: > Not to perpetuate a long discussion, but I personally find lots of > benefits in discussing multiple ways of achieving things on a list such as > this. I haven't dealt with file imports from a script in a while myself, > but the thing I picked up from this was the assemblies trick. In my > younger, more naive days, I wrote an importer and then proceeded to check > each node and see if it was a root node or not, looping over it as I went. > I found the returnNewNodes flag in the documentation for file, and used > that list, iterating manually over it with listRelatives. The assemblies > thing would have saved me a lot of loops there, and been much clearer to > read. It's all about building the toolbelt! > > > On 12/2/2014 4:26 AM, Christopher Crouzet wrote: > > @Marucs: WHAT ARE YOU TALKING ABOUT!? I AM ALREADY RELAXED!!!$#^(*&@ > > @Justin: my previous comments were only aimed towards avoiding premature > optimization but now that's another topic. Optimizations aside, I share > your point of view regarding your “first thought”. The idea is to code > using the tools that express the best the intentions of the developer. If > the idea is to have an unique set of elements, then a set is a good choice. > > Still, I'm subjectively happy with my choice of using a comprehensive > list in the context of the `bnn_importFile()` method because it was the > simplest to use. I'm a bit rusty with Python right now, so maybe I'm wrong, > but I believe that if I've had to implement that method using sets, then I > would have had to deal with needless conversions from/to lists, which would > have made the code less readable without any real improvement on my > intentions (I believe it's quite obvious already, and Marcus proved it)—I'm > not even talking here of the additional allocations that those conversions > would have probably caused on the heap, he he he! > > Btw, O(1) does provide better performances than O(n) when processing but > that would be forgetting the initialization-related costs. When the costs > of memory allocation due to a more complex data structure are significant > in comparison to the costs of the operations to process, then the O(1) > algorithm might lose versus the O(n) one in order of magnitudes. If I > remember well, that's what the C++ paper of vectors vs sets is talking > about. That's also why most of the time there is no universal trick to > increase performances and that benchmarking each snippet of code is the > only way to go when required, and hence why any optimization intuition > should be dismissed to focus solely on the code semantics. > > That being said... optimizations look fun! Can't wait to learn how to > dig into assembly code :) > > > On 2 December 2014 at 17:29, Justin Israel <[email protected]> wrote: > >> @Marcus, sorry if my suggestion was vague. My intention was that the list >> would be that returned from the file import call, when using the "return >> new nodes" flag. One could take that list and query for the assemblies. >> >> @Christopher, while I don't want to further propagate the off-topic >> discussion, I figured since we are already there, I might throw in my >> 2cents. I actually see valid points in both your comments as well as >> Marcus. I definitely agree that premature optimisation is the root of all >> evil. But what about cases where a certain idiom over another could yield a >> better possible outcome vs no change at all, simply by it becoming muscle >> memory? The way I see it, if you aren't expending any extra time trying to >> optimise a piece of code, and your first thought goes to "membership test >> in a loop... I'll use a set", did we lose anything by that? In this >> particular case, maybe using a set yields no quantifiable gain, but does >> the practice in doing so yield anything over time? Then again, in your >> defence you are correct that you did not ask for any help and your code was >> not meant to be the subject of evaluation. But either way, it was code >> provided, and we tend to spawn conversation on this list at random points. >> >> Again, I am just throwing in my thoughts on both sides. My own muscle >> memory would have made me write a set when looping and testing membership, >> at no extra "pre-optimization costs" to my development process. I just >> figure O(1) beats O(n) and if I am wrong, then it is still O(n). But then >> again no one was asking for opinions :-) >> >> >> On Tue, 2 Dec 2014 11:08 PM Christopher Crouzet < >> [email protected]> wrote: >> >>> I provided my suggestion because I knew that it would meet the >>> requirements of the question. Why would I need to describe its code? >>> >>> I'm not offended, it's just annoying to be linked to some >>> StackOverflow bullshit like if the answer there was some kind of holy graal >>> accurately providing a solution for all the problems in the universe. Even >>> though the author of the answer rightfully says that “it depends”, and >>> emphasizes on the need to time it, he still writes as a fact that sets are >>> significally faster when checking for uniqueness—thus without any sort of >>> proof. In which case is he right or wrong? Maybe it becomes true only when >>> using more than 100,000+ elements? Would the results still be the same for >>> large elements, or heterogeneous elements? I'd expect from you to be more >>> critic towards this kind of things. >>> >>> I'd also expect from you to not give such advices that you don't know >>> true for sure, especially since I haven't asked any help on the subject. If >>> I was a newbie, I would believe you as well as that author on SO, and maybe >>> I would go on rewriting all my codebase to use sets for such cases and tell >>> all my friends to do the same, until I'd realize 2 years later how wrong it >>> all is. All this when *we shouldn't even have been talking about this >>> matter* for such a non-critical code that is meant to run once and >>> where *readability prevails*. >>> >>> It's of course a stupid example but—and you can find some more >>> literature on the subject—all I'm trying to say here is to be careful on >>> what you say as it can/will influence others and might perpetuate bad >>> coding practices. >>> >>> Enough OT. >>> >>> >>> On 2 December 2014 at 16:27, Marcus Ottosson <[email protected]> >>> wrote: >>> >>>> Christopher, I’m sorry I didn’t read too carefully through your code, >>>> but you didn’t really provide much information to along with your >>>> suggestion to use your library for the task in the OP. >>>> >>>> and since you seem to enjoy reading development practices online >>>> >>>> I’m sensing I may have offended you, sorry about that. >>>> >>>> the number of items being checked for uniqueness within the list >>>> comprehension is most likely to be very (very) small >>>> >>>> My suggestion to use sets here was in regards to comparing all nodes >>>> contained within a file. Files may contain quite a few nodes, even in the >>>> hundreds of thousands, and in these cases I believe sets produce a >>>> noticeable difference. >>>> >>>> >>>> On 2 December 2014 at 09:08, Christopher Crouzet < >>>> [email protected]> wrote: >>>> >>>>> I believe you're wrong on both points. >>>>> >>>>> Firstly, the constructor of the iterator `bnn_MItDagHiearchy >>>>> <https://github.com/christophercrouzet/banana.maya/blob/master/banana/maya/extensions/OpenMaya/iterators.py#L214>` >>>>> has a default argument `recursive=false`, meaning that only the top >>>>> (assembly) DAG nodes will be returned, as expected by the >>>>> `bnn_importFile()` method. >>>>> >>>>> Secondly, and since you seem to enjoy reading development practices >>>>> online, you must know that you shouldn't talk about premature >>>>> optimizations >>>>> when there's no actual performance issues. Especially in this case where: >>>>> - the method `bnn_importFile()` most likely won't be used in a tight >>>>> loop. And even if it does, the performance limitations would come from the >>>>> actual import of the file incurred by Maya rather than from something as >>>>> insignificant as choosing between list-comprehension or sets. >>>>> - the number of items being checked for uniqueness within the list >>>>> comprehension is most likely to be very (very) small, and hence there more >>>>> likely won't be any noticeable difference in performances whatever method >>>>> is used, even if you decided to generate that list 17458 times in a row. >>>>> >>>>> >>>>> On 2 December 2014 at 15:31, Marcus Ottosson <[email protected]> >>>>> wrote: >>>>> >>>>>> Also as a variation to what Marcus suggested, instead of needing >>>>>> to first capture the assemblies in the scene, do the import, and compare >>>>>> the new assemblies listing to the old one with a set, you can just pass >>>>>> your list of nodes to ls() and have it return just the assemblies. >>>>>> >>>>>> The question is, which list do you pass? The reason for doing a >>>>>> before and after is getting the difference in order to figure out which >>>>>> nodes were imported, and which were already there. >>>>>> >>>>>> Using the Maya Python API: >>>>>> >>>>>> topLevelDagPaths = list(OpenMaya.bnn_MItDagHierarchy()) >>>>>> OpenMaya.MFileIO.importFile(fileName, type, preserveReferences, >>>>>> nameSpace, ignoreVersion)return [dagPath for >>>>>> dagPath in OpenMaya.bnn_MItDagHierarchy() >>>>>> if not dagPath in topLevelDagPaths] >>>>>> >>>>>> Which seems to iterate using >>>>>> OpenMaya.MItDag(OpenMaya.MItDag.kBreadthFirst) >>>>>> >>>>>> It looks like this will return *all* imported nodes, and not just >>>>>> the assembilies. In addition, finding differences via list-comprehension >>>>>> is >>>>>> about 100x slower than using sets. >>>>>> >>>>>> - http://stackoverflow.com/questions/2831212/python-sets-vs-lists >>>>>> >>>>>> >>>>>> >>>>>> On 1 December 2014 at 23:42, Christopher Crouzet < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Using the Maya Python API: >>>>>>> https://github.com/christophercrouzet/banana.maya/blob/master/banana/maya/extensions/OpenMaya/MFileIO.py#L19 >>>>>>> >>>>>>> >>>>>>> On 2 December 2014 at 05:54, Justin Israel <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Also as a variation to what Marcus suggested, instead of needing to >>>>>>>> first capture the assemblies in the scene, do the import, and compare >>>>>>>> the >>>>>>>> new assemblies listing to the old one with a set, you can just pass >>>>>>>> your >>>>>>>> list of nodes to ls() and have it return just the assemblies: >>>>>>>> >>>>>>>> cmds.ls(nodes, assemblies=True) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue Dec 02 2014 at 11:05:59 Marcus Ottosson < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> That's a clever approach! >>>>>>>>> >>>>>>>>> Along those lines, you could also opt to import files under a >>>>>>>>> given namespace; all nodes, including non-DAG ones, will end up >>>>>>>>> within the >>>>>>>>> namespace. As a side-note, this is probably as close as you'll get to >>>>>>>>> the >>>>>>>>> Softimage "Model". >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CAFRtmOABXtVoG4ruZHg%3DyBMc3oCiRN3mZcoT38J63UcZznj0wA%40mail.gmail.com >>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOABXtVoG4ruZHg%3DyBMc3oCiRN3mZcoT38J63UcZznj0wA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CAPGFgA3mmgOK4BLFdXZAm_bs7s%2BvfEgyVr-YQkf%2BLPjy%3DM-mYQ%40mail.gmail.com >>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3mmgOK4BLFdXZAm_bs7s%2BvfEgyVr-YQkf%2BLPjy%3DM-mYQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>>>>>> >>>>>>>> >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Christopher Crouzet >>>>>>> *http://christophercrouzet.com* <http://christophercrouzet.com> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CANuKW501RmgWsAnNCj-CWQF2w3%2Bv1owr9KCAwFmaZDsgChs8Jw%40mail.gmail.com >>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW501RmgWsAnNCj-CWQF2w3%2Bv1owr9KCAwFmaZDsgChs8Jw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Marcus Ottosson* >>>>>> [email protected] >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CAFRtmOAhMU30FaYfqQ1QsOj%3DUdUkuwWWHL8COTp8Tk6em3mDVQ%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAhMU30FaYfqQ1QsOj%3DUdUkuwWWHL8COTp8Tk6em3mDVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Christopher Crouzet >>>>> *http://christophercrouzet.com* <http://christophercrouzet.com> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CANuKW52KLkM1hMXVqGodK41Yep8gX%3Dd0isoN0r%2BxcQWXSqxLZA%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW52KLkM1hMXVqGodK41Yep8gX%3Dd0isoN0r%2BxcQWXSqxLZA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> *Marcus Ottosson* >>>> [email protected] >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CAFRtmODS%2Bj8qweKoSWFTm4Tosbj-MS6SKTZB_ghXU_DPQKS4uQ%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODS%2Bj8qweKoSWFTm4Tosbj-MS6SKTZB_ghXU_DPQKS4uQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>> >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Christopher Crouzet >>> *http://christophercrouzet.com* <http://christophercrouzet.com> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CANuKW537NmV-dL147iCU%3DnhOOQ3ZGF1hqPngmC91c8okN3%2BoXg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW537NmV-dL147iCU%3DnhOOQ3ZGF1hqPngmC91c8okN3%2BoXg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" 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/python_inside_maya/CAPGFgA0vFV6CDKofGnNkcwoSY3c4BhRAUakPZy-4rnnBFAKS1w%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0vFV6CDKofGnNkcwoSY3c4BhRAUakPZy-4rnnBFAKS1w%40mail.gmail.com?utm_medium=email&utm_source=footer>. >> >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Christopher Crouzet > *http://christophercrouzet.com* <http://christophercrouzet.com> > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" 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/python_inside_maya/CANuKW53%3Doa9LrxJhcKJZL1zyG%2B08cn1gCUr8SmqZb-a2ZZTVHQ%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CANuKW53%3Doa9LrxJhcKJZL1zyG%2B08cn1gCUr8SmqZb-a2ZZTVHQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > > > ------------------------------ > <http://www.avast.com/> > > This email is free from viruses and malware because avast! Antivirus > <http://www.avast.com/> protection is active. > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" 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/python_inside_maya/547DEE42.6080504%40gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/547DEE42.6080504%40gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" 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/python_inside_maya/CAPGFgA3K3j9OuAxnjNbofHP3aAEN9%3DejVYDnfsK2fZoi1whDpg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
