[sage-devel] Re: arithmetic with True and False

2010-07-24 Thread mda_
On Jul 24, 2:29 pm, Burcin Erocal wrote: > [...] > At Sage Days 24, I learned that Python allows the user to do arithmetic > with bools: > > In [1]: 5+True > Out[1]: 6 > [...] > Any comments? Preface: Python is my favorite language. These are just comments, no flames please. However, for the u

[sage-devel] Re: arithmetic with True and False

2010-07-25 Thread mda_
On Jul 25, 1:50 am, Marco Streng wrote: > [...] > I like the TypeError here to avoid bugs, but don't mind following > python convention either. http://docs.python.org/library/warnings.html Maybe using (soft) warnings in the interim (while maintaining workarounds) could be a compromise between g

[sage-devel] Re: sage-vmware-4.4.alpha0.zip Corrupted?

2010-07-27 Thread mda_
> One possibility is we could split the file, then you download each part > separately. Then the md5 checksum of each part could be checked individually. > If > one gets corrupted, only that part would need to be downloaded again. You > would > of course need to rebuild the constituent parts. It

[sage-devel] Re: sage-vmware-4.4.alpha0.zip Corrupted?

2010-07-27 Thread mda_
> > It may be easier to enable a bittorrent server on a mirror. [...] > > Possibly, but that's more hassle in the short term. I don't know what's > involved. In any case, I can't do it as I don't control the server. Well, there are no perfect solutions, but it is an option. Maybe in 5 or 10 years

[sage-devel] Re: Semicolons in doctests

2010-07-30 Thread mda_
> i.e. the following produces no output: > sage: 42; > > However, in doctests, it *does* produce output, the same line in a > doctest would give: > ** > File "/home/jdemeyer/printtest.sage", line 6: >     sage: 42; > Expected nothi

[sage-devel] Re: sage-vmware-4.4.alpha0.zip Corrupted?

2010-07-31 Thread mda_
> [1]http://www.sagemath.org/mirror/win/meta/sage-vmware-4.4.alpha0.zip.me... > [2]http://aria2.sourceforge.net/ > > I'm not aware of a better solution to handle this problem ... > > H Harald: I think metalinks are great, indeed, the metalink file you reference contains a torrent file reference

[sage-devel] Re: Polynomials are immutable (really?)

2010-08-02 Thread mda_
SageDevs, In the interest of "gotchas", please consider the following: The built-in str, and the module string are different, though both return type str according to type(). Example: d...@dv9000-laptop:~$ python2.6 Python 2.6.4 (r264:75706, Dec 7 2009, 18:43:55) [GCC 4.4.1] on linux2 Type "he

[sage-devel] Re: Polynomials are immutable (really?)

2010-08-02 Thread mda_
Caveat: Hopefully my chaining of operators there didn't mislead, that was unintended. I think most of what I said still holds, if not all. -Don On Aug 2, 9:14 am, mda_ wrote: > SageDevs, > > In the interest of "gotchas", please consider the following: > > Th

[sage-devel] Re: Polynomials are immutable (really?)

2010-08-02 Thread mda_
Another Caveat: str doesn't implement .__copy__ or .__deepcopy__ so I'm being sillybut the main point being "is" is object comparison not equality. Ok, email on exponential backoff!! ;-) On Aug 2, 11:06 am, mda_ wrote: > Caveat: Hopefully my chaining of operators the

[sage-devel] Re: Polynomials are immutable (really?)

2010-08-02 Thread mda_
bad form unless you are working with an object that is mutable. I hope it's not making a double reference, that would be bad design. I apologize for glossing over your explicit statement that str are immutable. Indeed. I could have reduced my emails by [4,3]. On Aug 2, 1:22 pm, mda_ wrote

[sage-devel] Re: Polynomials are immutable (really?)

2010-08-02 Thread mda_
> str  is very much immutable. > So you can't even set some custom attribute. I found a way to cheat. =) Python 2.6 has backported the Python 3000 bytearray() method, which is basically just a mutable str. No import statement needed. http://www.python.org/dev/peps/pep-3112/ So you can copy yo

[sage-devel] Zumkeller Numbers

2010-08-02 Thread mda_
I wrote the following zumkeller number verification function today, if anyone's interested. I verified its correctness for the first 10,000 terms (from the OEIS site) in the domain: 1 < n < 43465. Computation for that range took 1 hour, 26 minutes, 5.17 seconds =) Is it fast or slow? def is_zk(

[sage-devel] Re: Zumkeller Numbers

2010-08-02 Thread mda_
> Calling sigma() involves a call to factor(), so you are basically > factoring your input *twice* every time (I think; someone should correct > me if I'm wrong) -- bad idea! I would move the "d > = divisors(a)" to the top, and then do > >     sa = sum(d) You're right, I made that same optimizatio

[sage-devel] Re: Zumkeller Numbers

2010-08-02 Thread mda_
Also I forgot to parallelize it. It currently only runs on one core. I have two on this laptop. =) -- 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

[sage-devel] Re: Zumkeller Numbers

2010-08-03 Thread mda_
On Aug 3, 7:38 am, YannLC wrote: > Here is my version, Thanks Yann! I'm going to write a version in Cython. A guy on the OEIS list got about a 100x speed up with shedskin. Pypy was close to the shedskin mark, and he never finished his Cython port (properly) to judge Cython fairly. > def is_z

[sage-devel] Re: Zumkeller Numbers

2010-08-03 Thread mda_
>  I still like returning the number instead of True. I take it back. I'm wrong, as noted in the other thread. I can't assume the caller will coerce the return type with bool(). Can I get an A for effort? =) Had a bad day.. -- To post to this group, send an email to sage-devel@googlegroup

[sage-devel] Re: Zumkeller Numbers

2010-08-03 Thread mda_
> No need to call is_prime(a), divisors would only return length two; > otherwise the sieving is done twice.  (Unless Sage does something > extra smart behind the scenes.) What I said above is wrong, remembering there are faster algorithms, and digging through rings/integer.pyx I see hybrid is_pri

[sage-devel] Re: Zumkeller Numbers

2010-08-03 Thread mda_
Wow, thanks. I didn't see your post just as I sent my retraction. I'll definitely play with this some tonight. I'm going to calculate very far, then do an intersection with is_squarefree() just out of curiousity. On Aug 3, 5:26 pm, YannLC wrote: > Here is a cython version suitable only for ints

[sage-devel] Re: complementary problem

2010-08-04 Thread mda_
Wow, I'm 100% certain I have nothing to add to this quandary, and couldn't possibly know the correct answer/choice, only supply the link to the relevant context Robert refers to: http://docs.python.org/release/3.0.1/whatsnew/3.0.html#ordering-comparisons Down the rabbit hole indeed. D On Aug 4,

[sage-devel] Re: complementary problem

2010-08-04 Thread mda_
> An alternative approach would be to realise that vertices need to be > stored in a sequence that has quick membership testing, for instance a > dictionary {'v1': 0, 'v2':1} etc. Depending on the type of access, > perhaps you would also need to keep the thing as a sequence > ['v1','v2']. In magma,

[sage-devel] Re: complementary problem

2010-08-04 Thread mda_
> > I don't know how easy it is to make such a data structure efficient > > and what the memory penalty is for having both hashing and ordering. > > http://docs.python.org/py3k/whatsnew/3.1.html#pep-372-ordered-diction... > > The reference implementation in the PEP(372) states "O(n)" for > deletion

[sage-devel] Re: complementary problem

2010-08-04 Thread mda_
> Another except from the PEP: "A version written in C could use a > linked list. The code would be more complex than the other two > approaches but it would conserve space and would keep the same big-oh > performance as regular dictionaries. It is the fastest and most space > efficient." The trad

[sage-devel] Re: complementary problem

2010-08-04 Thread mda_
> Hopefully this all agrees with you, and if not, I guess I can start > learning Lisp... My apologies for the cross-posting (I am not yet approved for sage- flame) http://www.buayacorp.com/wp-content/uploads/2007/10/john-mccarthy-poster1.jpg (Above: A portrait, and tribute! ;-), to the inven

[sage-devel] Re: complementary problem

2010-08-04 Thread mda_
> The fact that you're "doing it" at all implies the imperative which, as > we all know, is not the way to program (this week). http://en.wikipedia.org/wiki/Touché my friend(?) =) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an ema

[sage-devel] Re: IDE's; science/engineering

2010-08-12 Thread mda_
> >  - LD_LIBRARY_PATH means people must either mess big-time with > > environment variables, or start using "sage -python" and "sage - > > ipython" (in which case all the examples about using Python from the > > internet, scripts with shebangs "#!/usr/bin/env python" etc. stops > > working). > > W

[sage-devel] Re: complementary problem

2010-08-12 Thread mda_
> >>ordering, I'm just suggesting that since there is an inconsistent > >> definition of < for Sage sets, and since they get used frequently as > >> vertices, that we define atotalordering. You yourself admitted that > >> you can't think of a natural mathematical meaning for < for arbitrary > >> s

[sage-devel] Re: Should there be some *good* examples on notebook?

2010-08-12 Thread mda_
> There's going to get some examples to look at, and they are going to be decent > ones. They make Mathematica look very easy - only later do you find out that > its > far from a trivial program to use well. Programming isn't trivial in general. Python is very productive precisely because of its

[sage-devel] Re: Should there be some *good* examples on notebook?

2010-08-16 Thread mda_
On Aug 16, 12:39 am, Tom Boothby wrote: > > I just wrote a worksheet that I'd be willing to share in this manner > > (and release to public domain, cc, etc).  I'll have to add some > > documentation, but other than that, it's ready to go. > > Money where my mouth is: > > http://sagenb.org/home/pub

[sage-devel] Re: Should there be some *good* examples on notebook?

2010-08-16 Thread mda_
> On Aug 16, 12:39 am, Tom Boothby wrote: > > > > I just wrote a worksheet that I'd be willing to share in this manner > > > (and release to public domain, cc, etc).  I'll have to add some > > > documentation, but other than that, it's ready to go. > > > Money where my mouth is: > > >http://sagen

[sage-devel] Re: sympow

2010-08-16 Thread mda_
> system to be more modular. Is there even an efficient method in Python > of conditionally including code based on availability of prereqs? I Since I'm a sage-noob, I don't know if my answer is relevant enoughHowever, the import statement in python, in general, has been misused in the past.

[sage-devel] Re: How does real_lazy work?

2010-08-16 Thread mda_
On Jul 31, 6:22 pm, Mike Hansen wrote: >[...] > Again, please stop spreading FUD about the category code. > > --Mike Isn't the FUD acronym trademarked and copyrighted by the GNU folks? ;) Tom Boothby: What new word(s) can you create to describe these "Inter-License Affairs"? If the SAGE acrony

[sage-devel] bug? is_triangular_number(0), Range Types: Bool, Integer

2010-09-08 Thread mda_
sage: is_triangular_number(0) 0 sage: is_triangular_number(1) 1 sage: is_triangular_number(2) False sage: is_triangular_number(3) 2 This is the same duck-typing style choice I made before. Example where unexpected output is generated: sage: [x for x in [0..3] if not is_triangular_number(x)] [0,

[sage-devel] bug? is_even(e), No Duck Coercion of Argument sage.symbolic.constants_c.E

2010-09-08 Thread mda_
sage: is_even(e) TypeError: unsupported operand type(s) for %: 'sage.symbolic.constants_c.E' and 'int' sage: is_even(float(e)) False -- 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 F

[sage-devel] Re: bug? is_even(e), No Duck Coercion of Argument sage.symbolic.constants_c.E

2010-09-08 Thread mda_
On Sep 8, 5:12 pm, mda_ wrote: > sage: is_even(e) > TypeError: unsupported operand type(s) for %: > 'sage.symbolic.constants_c.E' and 'int' > > sage: is_even(float(e)) > False sage: is_odd(float(e)) True sage: is_odd(int(e)) False -- To post to t

[sage-devel] bug? float(i^i); TypeError: unable to simplify to float approximation

2010-09-12 Thread mda_
Also, sage: float(e^(-pi/2)) 0.20787957635076193 The last digit should be 1, since i^i = 0.20787957635076190854 sage does not recognize this identity: sage: e^(-pi/2) == i^i e^(-1/2*pi) == I^I ("True" expected as output.) What's the best way to ask sage for floating point approximatio

[sage-devel] Re: bug? float(i^i); TypeError: unable to simplify to float approximation

2010-09-12 Thread mda_
On Sep 12, 5:44 pm, Mitesh Patel wrote: >[...] > This appears to work: > > sage: bool(e^(-pi/2) == i^i) > True Thanks Mitesh. What is the sage convention for returning the object as a result of "==" instead of bool when the result is not False? Is it ad hoc? Would you consider float(i^i) rais

[sage-devel] Re: bug? float(i^i); TypeError: unable to simplify to float approximation

2010-09-14 Thread mda_
On Sep 13, 5:53 pm, Mitesh Patel wrote: > On 09/12/2010 10:19 PM, mda_ wrote: > > > On Sep 12, 5:44 pm, Mitesh Patel wrote: > >> [...] > >> This appears to work: > > >> sage: bool(e^(-pi/2) == i^i) > >> True > > > Thanks Mitesh.  W

[sage-devel] Re: Suggestion to provide external links in documentation.

2010-09-21 Thread mda_
On Sep 21, 10:39 am, "Dr. David Kirkby" wrote: > On 09/21/10 06:12 PM, Niles wrote: > > > I'd just like to comment that, if the wording "nearest Mathematica > > equivalent" is going to be an essential part of this, then it should > > be very carefully chosen, and probably implemented through some

[sage-devel] Re: Suggestion to provide external links in documentation.

2010-09-21 Thread mda_
> > How about "close analogue". > > No, I don't like that. If nothing else, it will be more confusing to those > whose > first language is not English, and even though mine is, I don't like that > term. Tom Boothby can "inventor" a word. I do like "analogues" though. m-w.com: "1:something tha

[sage-devel] Re: bug? sage.combinat.sloane_functions.A111776

2010-09-27 Thread mda_
On Sep 25, 4:17 am, YannLC wrote: > sage: sloane.A111776 seems to be in fact (almost) > A109814.http://www.research.att.com/~njas/sequences/A109814 New Ticket #10025 http://trac.sagemath.org/sage_trac/ticket/10025 -- To post to this group, send an email to sage-devel@googlegroups.com To unsub