On Jan 29, 8:46 pm, Dima Pasechnik <dimp...@gmail.com> wrote: > it shows, by the way, that idea to use set() (or Set()) to remedy > differences in docstrings with > the output of randomised procedures, discussed > here:http://groups.google.com/group/sage-devel/browse_thread/thread/1f688f... > does not really fly.
How does it show this? If your expected output is a list [x,y] or [y,x], but you can't tell which, then sage: set(OUTPUT) == set([x,y]) True sage: x in OUTPUT True sage: y in OUTPUT True sage: len(OUTPUT) 2 I see that you can't do sage: OUTPUT set([x,y]) but why not the other options? I feel like I'm missing something... > On Jan 30, 10:38 am, kcrisman <kcris...@gmail.com> wrote: > > > > > On #7325, we are getting hardware or software-dependent results, which > > are easy to deal with as the results are equivalent, but which raises > > the question of how to correctly use of Python's set(). > > > On sage.math: > > sage: set((x,y)) > > set([y, x]) > > > On my Macintel 10.5: > > sage: set((x,y)) > > set([x, y]) > > > Then when one makes an iterator, it becomes dependent on this. set() > > is a pure Python thing, I believe. Can anyone shed light on this - to > > be precise, how to avoid this dependence in making an iterator without > > (say) sorting? Has this ever caused problems in Sage before? I think you should only use set when you don't care about ordering. That's its whole point, right? -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
