[sage-devel] Re: coercing of log(2)*1.0
On 1 Jun., 18:56, Carl Witty <[EMAIL PROTECTED]> wrote: > Sage has such a decision procedure built in to its implementation of > QQbar, the algebraic numbers. But I have to say they are quite hidden in the reference manual. Thank you for this hint. I also found AA the algebraic reals if your computations only involve reals. > sage: QQbar(sqrt(-2)*sqrt(-3) + sqrt(6)) == 0 > True Using QQbar or AA also my previous example works: QQbar(sqrt(5+2*sqrt(2)*sqrt(3))-sqrt(2)-sqrt(3)) == 0 True AA(sqrt(5+2*sqrt(2)*sqrt(3))-sqrt(2)-sqrt(3)) == 0 True However is it a *bug* that this does not work in the symbolic Ring with is_zero? (sqrt(5+2*sqrt(2)*sqrt(3))-sqrt(2)-sqrt(3)).is_zero() False And good to know that with QQbar or AA the rule of coercing to the lowest precision works. AA(sqrt(2))*1.0 1.41421356237309 QQbar(sqrt(2)) * CC(1.0) 1.41421356237309 But back to SymbolicRing and SymbolicConstant. I have the following improvement SUGGESTION: when creating sqrt(2) or other roots from integers, then assign to them the parent AlgebraicReal or AlgebraicNumer accordingly instead of the too general Symbolic Ring. Coercing (see above) and calculating with AA and QQbar works well, for example: sqrt(AA(sqrt(2))).parent() Algebraic Real Field sqrt(-AA(sqrt(2))).parent() Algebraic Field For future development maybe one can introduce a RealSymbolicConstant (and ComplexSymbolicConstant) which allow application of the common real functions like +,-,*,/,^, exp, log, sin, cos, etc. However the difficulty I see here is that we must be able to decide whether such an expression is 0 if we want to reject expr1/expr2 or log(expr2) for expr2 being 0. We also must be able to decide whether such an expression is greater 0. When we want to determine the outcome (RealSymbolicConstant or ComplexSymbolicConstant) of log(expr) or expr ** (1/n). So maybe this isnt possible from a theoretical point of view as those questions maybe undecidable (opposed to the algebraic case) which however is not yet clear for me. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Improving rescaling of matrices
Referring to http://trac.sagemath.org/sage_trac/ticket/3212, I have to
do a little cleaning up before submitting it for review, but have some
code for allowing rescaling of matrices by "logical" scalars not in
the base ring. However, in order to do this, I need to return a copy,
not modify the original, and robertwb raises the point that perhaps
then rescale_row etc. should *always* return a copy, for
consistency.
I don't feel at all qualified to make this decision, and wanted some
feedback. This seems like it could break other code which assumes
that a new reference doesn't have to be created, but of course this is
a place where inconsistency could be very confusing too. Another
option is to scrap the idea altogether, but then we continue to have
the problem that one couldn't scale a row by an element of an
extension of the field of fractions of the base ring (e.g., one
couldn't scale a row of a matrix over QQ by I or \sqrt{2}).
Thanks for any feedback.
- kcrisman
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Improving rescaling of matrices
kcrisman wrote: > Referring to http://trac.sagemath.org/sage_trac/ticket/3212, I have to > do a little cleaning up before submitting it for review, but have some > code for allowing rescaling of matrices by "logical" scalars not in > the base ring. However, in order to do this, I need to return a copy, > not modify the original, and robertwb raises the point that perhaps > then rescale_row etc. should *always* return a copy, for > consistency. +1 to always returning a copy. If *anything* is returned, I would expect it to be a copy. Note that one convention that I have observed in python is to return None if an object is modified by a method. You see this in the sort() method for lists, for example. We have also tried to follow this convention in the graph theory code (and we've had this discussion before when contemplating changing the graph theory code). Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann <[EMAIL PROTECTED]> wrote: > > On 1 Jun., 18:56, Carl Witty <[EMAIL PROTECTED]> wrote: >> Sage has such a decision procedure built in to its implementation of >> QQbar, the algebraic numbers. > > But I have to say they are quite hidden in the reference manual. > Thank you for this hint. I also found AA the algebraic reals if your > computations only involve reals. > >> sage: QQbar(sqrt(-2)*sqrt(-3) + sqrt(6)) == 0 >> True > > Using QQbar or AA also my previous example works: > QQbar(sqrt(5+2*sqrt(2)*sqrt(3))-sqrt(2)-sqrt(3)) == 0 > True > AA(sqrt(5+2*sqrt(2)*sqrt(3))-sqrt(2)-sqrt(3)) == 0 > True > > However is it a *bug* that this does not work in the symbolic Ring > with is_zero? > (sqrt(5+2*sqrt(2)*sqrt(3))-sqrt(2)-sqrt(3)).is_zero() > False The definition of is_zero in the Sage symbolic ring is currently *precisely* the definition in Maxima. In fact, most of the functionality of the Sage symbolic ring is just a light wrapper around Maxima, though when we found bugs that Maxima couldn't fix (e.g., in floor/ceiling), we have worked around them. Work is under way to completely rewrite the symbolic ring. > And good to know that with QQbar or AA the rule of coercing to the > lowest precision works. > AA(sqrt(2))*1.0 > 1.41421356237309 > QQbar(sqrt(2)) * CC(1.0) > 1.41421356237309 > > But back to SymbolicRing and SymbolicConstant. > I have the following improvement > SUGGESTION: when creating sqrt(2) or other roots from integers, then > assign to them the parent AlgebraicReal or AlgebraicNumer accordingly > instead of the too general Symbolic Ring. > That's definitely planned. > Coercing (see above) and calculating with AA and QQbar works well, for > example: > sqrt(AA(sqrt(2))).parent() > Algebraic Real Field > sqrt(-AA(sqrt(2))).parent() > Algebraic Field > > For future development maybe one can introduce a RealSymbolicConstant > (and ComplexSymbolicConstant) which allow application of the common > real functions like +,-,*,/,^, exp, log, sin, cos, etc. However the > difficulty I see here is that we must be able to decide whether such > an expression is 0 if we want to reject expr1/expr2 or log(expr2) for > expr2 being 0. We also must be able to decide whether such an > expression is greater 0. When we want to determine the outcome > (RealSymbolicConstant or ComplexSymbolicConstant) of log(expr) or expr > ** (1/n). So maybe this isnt possible from a theoretical point of view > as those questions maybe undecidable (opposed to the algebraic case) > which however is not yet clear for me. Thanks for your comments. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Mon, Jun 2, 2008 at 9:45 AM, Carl Witty <[EMAIL PROTECTED]> wrote: > > On Jun 2, 9:17 am, "William Stein" <[EMAIL PROTECTED]> wrote: >> On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann >> > But back to SymbolicRing and SymbolicConstant. >> > I have the following improvement >> > SUGGESTION: when creating sqrt(2) or other roots from integers, then >> > assign to them the parent AlgebraicReal or AlgebraicNumer accordingly >> > instead of the too general Symbolic Ring. >> >> That's definitely planned. > > Actually, if you mean that sqrt(2) should become the same as > AA(sqrt(2)) is now, I'm not sure that's a good idea, for two reasons. > First, AA and QQbar by design don't maintain enough information to > print nicely. (This could be improved somewhat from the current > state, but not enough to compete with symbolic radical expressions.) > Second, since AA and QQbar incorporate complete decision procedures, > it is easy to construct examples where they are very, very slow; I > think people would often be happier with the less complete but much > faster techniques used in symbolics. I think the plan is that algebraic elements won't just be generic symbolic elements, e.g., sqrt(2) would be a generator for ZZ[sqrt(2)]. This has been discussed a few times.I didn't mean that using AA or QQbar by default was precisely what is planned. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Jun 2, 9:17 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann > > But back to SymbolicRing and SymbolicConstant. > > I have the following improvement > > SUGGESTION: when creating sqrt(2) or other roots from integers, then > > assign to them the parent AlgebraicReal or AlgebraicNumer accordingly > > instead of the too general Symbolic Ring. > > That's definitely planned. Actually, if you mean that sqrt(2) should become the same as AA(sqrt(2)) is now, I'm not sure that's a good idea, for two reasons. First, AA and QQbar by design don't maintain enough information to print nicely. (This could be improved somewhat from the current state, but not enough to compete with symbolic radical expressions.) Second, since AA and QQbar incorporate complete decision procedures, it is easy to construct examples where they are very, very slow; I think people would often be happier with the less complete but much faster techniques used in symbolics. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] hi
Dear friend: we are an electronical wholesale company which locates in China,we have lots of good products with high quality and low price; such as digital cameras, mobile, LCD TV, Laptops Notebooks, Digital Video, Mp4, GPS, and so on. In order to gratulate Olympic Games of 2008 in Beijing, our company have a favourable campaign in this month; buy more, get more discount; This is a god-given chance. we hope you can hold it quickly. Have a nice day; thanks website: www.elec-selling.com MSN: [EMAIL PROTECTED] Email : [EMAIL PROTECTED] email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Improving rescaling of matrices
On Mon, Jun 2, 2008 at 7:17 AM, Jason Grout <[EMAIL PROTECTED]> wrote: > > kcrisman wrote: >> Referring to http://trac.sagemath.org/sage_trac/ticket/3212, I have to >> do a little cleaning up before submitting it for review, but have some >> code for allowing rescaling of matrices by "logical" scalars not in >> the base ring. However, in order to do this, I need to return a copy, >> not modify the original, and robertwb raises the point that perhaps >> then rescale_row etc. should *always* return a copy, for >> consistency. > > +1 to always returning a copy. Do you have any idea what making this change is going to do to the generic echelonize() command? It's just not going to work at all or be insanely slow. > If *anything* is returned, I would expect it to be a copy. > > Note that one convention that I have observed in python is to return > None if an object is modified by a method. You see this in the sort() > method for lists, for example. We have also tried to follow this > convention in the graph theory code (and we've had this discussion > before when contemplating changing the graph theory code). It's not just a convention. In the Python language *all* functions return a value whether you use the return command or not. If you don't they default to returning None. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] hi again
Hello. The last email you just received "from me" was in fact from a spammer impersonating my email account. I'm sorry for any inconvenience this may cause. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Improving rescaling of matrices
On Mon, Jun 2, 2008 at 10:17 AM, Carl Witty <[EMAIL PROTECTED]> wrote: > > On Jun 2, 9:31 am, "William Stein" <[EMAIL PROTECTED]> wrote: >> On Mon, Jun 2, 2008 at 7:17 AM, Jason Grout <[EMAIL PROTECTED]> wrote: >> >> > kcrisman wrote: >> >> Referring tohttp://trac.sagemath.org/sage_trac/ticket/3212, I have to >> >> do a little cleaning up before submitting it for review, but have some >> >> code for allowing rescaling of matrices by "logical" scalars not in >> >> the base ring. However, in order to do this, I need to return a copy, >> >> not modify the original, and robertwb raises the point that perhaps >> >> then rescale_row etc. should *always* return a copy, for >> >> consistency. >> >> > +1 to always returning a copy. >> >> Do you have any idea what making this change is going to do to >> the generic echelonize() command? It's just not going to work at all >> or be insanely slow. > > Maybe rescale_row and rescale_col should retain their current > semantics, and we should have new methods with_rescaled_row and > with_rescaled_col that always return a modified copy and never modify > the original. Then rescale_row and rescale_col could catch the type > error from #3212, and produce a new type error that says something > like "rescale_row cannot change the base ring of the matrix; try > with_rescaled_row instead". > +1 -- that's a great idea! William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Improving rescaling of matrices
On Jun 2, 9:31 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 7:17 AM, Jason Grout <[EMAIL PROTECTED]> wrote: > > > kcrisman wrote: > >> Referring tohttp://trac.sagemath.org/sage_trac/ticket/3212, I have to > >> do a little cleaning up before submitting it for review, but have some > >> code for allowing rescaling of matrices by "logical" scalars not in > >> the base ring. However, in order to do this, I need to return a copy, > >> not modify the original, and robertwb raises the point that perhaps > >> then rescale_row etc. should *always* return a copy, for > >> consistency. > > > +1 to always returning a copy. > > Do you have any idea what making this change is going to do to > the generic echelonize() command? It's just not going to work at all > or be insanely slow. Maybe rescale_row and rescale_col should retain their current semantics, and we should have new methods with_rescaled_row and with_rescaled_col that always return a modified copy and never modify the original. Then rescale_row and rescale_col could catch the type error from #3212, and produce a new type error that says something like "rescale_row cannot change the base ring of the matrix; try with_rescaled_row instead". Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: log vs log_b
On Jun 1, 2008, at 2:13 AM, Martin Albrecht wrote: > >> I didn't even know there was a log_b, so I would be *very* happy >> to delete it. >> >> -- William > > They are not the same: > > sage: log_b(10,2) > 3.32192809489 > sage: log(10,2) > log(10)/log(2) > > but log(10,2).n() is. I don't think we need a separate log_b command for that. However, this has always annoyed me: sage: log(10.0,2) 3.32192809488736 sage: log(10,2.0) 1.44269504088896*log(10) - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
On May 31, 2008, at 8:45 AM, Andrey Novoseltsev wrote: > I looked at the new site the second time and liked it much more! Me too, even better than last time. > Some other ideas/comments: > 1) I think that the main page would look better if "Our mission" is in > bold and starts a separate paragraph. I was thinking along the same lines, but now that I see it I'm not so sure. Also, I think it might be better for the text to be left- justified (but still centered in the page). > 2) Navigation buttons and their labels look great, but "sublabels" are > very small (smaller than commong text on pages) and I think they would > look better if they were arranged vertically rather than horizontally. Perhaps it would look better if the label was vertically centered on the graphic (or at least more so) rather than the sub-label being centered there. > 3) The top and bottom of "Download and Media" header on the download > page are cut in Firefox under WinXP with large fonts on. > 4) Maybe some links to "DVD" and "Additional packages" on the top of > this page would be useful. Or maybe sections "Binaries", "Source", > "DVD", "Additional packages" would look nice with subsections in > "Binaries" for each particular system. How hard would it be to sort these by platform (according to browser information?). I'm usually against OS-specific customizations, but this is somewhere that makes sens. Right now the Windows download is the only thing I see (have to scroll down for other options). I think the blurb could be shorter too (just say a native port is in the works). > Minor/cosmetic: > 5) Lists of the form "1. lower case" look weird to me and I'd rather > have "1. Upper case" or "1) lower case" > 6) Black "the" in front of blue "VMWare Image of Sage" looks strange > too, I would remove it or put into the link as well. > 7) After "Apple MacOS" and "Source" links should start with capital > letters. > > 8) Maybe emphasize in "DVD" section that one can freely make extra > copies of the bought DVD and use on as many machines as desired? +1 > 9) It is also not very clear what exactly is "Sage on DVD" - source > code, binaries, "live DVD," all of it? It is explained on the order > page, but can be added to the site as well, I think. Good point. For the record, it's source + binaries for OS X/VMware/ linux + documentation. It's mostly for people with limited bandwidth or who like to hold a physical DVD, provided at cost (zero revenue for us). - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] quantitative finance in sage
Hi, I've posted a first very very (very) minimal "quantitative finance" piece of code here: http://trac.sagemath.org/sage_trac/ticket/3346 I hope somebody who has some interest in this area will referee it. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Improving rescaling of matrices
William Stein wrote: > On Mon, Jun 2, 2008 at 7:17 AM, Jason Grout <[EMAIL PROTECTED]> wrote: >> kcrisman wrote: >>> Referring to http://trac.sagemath.org/sage_trac/ticket/3212, I have to >>> do a little cleaning up before submitting it for review, but have some >>> code for allowing rescaling of matrices by "logical" scalars not in >>> the base ring. However, in order to do this, I need to return a copy, >>> not modify the original, and robertwb raises the point that perhaps >>> then rescale_row etc. should *always* return a copy, for >>> consistency. >> +1 to always returning a copy. > > Do you have any idea what making this change is going to do to > the generic echelonize() command? It's just not going to work at all > or be insanely slow. That's one reason why I vote +1 to the suggestion in the other thread to have two different functions (just like "echelonize" and "echelon_form"). > >> If *anything* is returned, I would expect it to be a copy. >> >> Note that one convention that I have observed in python is to return >> None if an object is modified by a method. You see this in the sort() >> method for lists, for example. We have also tried to follow this >> convention in the graph theory code (and we've had this discussion >> before when contemplating changing the graph theory code). > > It's not just a convention. In the Python language *all* functions return > a value whether you use the return command or not. If you don't they > default to returning None. When I said *anything*, I meant "If a matrix is returned (in this case)" --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Improving rescaling of matrices
On Jun 2, 2008, at 10:19 AM, William Stein wrote: > > On Mon, Jun 2, 2008 at 10:17 AM, Carl Witty <[EMAIL PROTECTED]> > wrote: >> >> On Jun 2, 9:31 am, "William Stein" <[EMAIL PROTECTED]> wrote: >>> On Mon, Jun 2, 2008 at 7:17 AM, Jason Grout >> [EMAIL PROTECTED]> wrote: >>> kcrisman wrote: > Referring tohttp://trac.sagemath.org/sage_trac/ticket/3212, I > have to > do a little cleaning up before submitting it for review, but > have some > code for allowing rescaling of matrices by "logical" scalars > not in > the base ring. However, in order to do this, I need to return > a copy, > not modify the original, and robertwb raises the point that > perhaps > then rescale_row etc. should *always* return a copy, for > consistency. >>> +1 to always returning a copy. >>> >>> Do you have any idea what making this change is going to do to >>> the generic echelonize() command? It's just not going to work at >>> all >>> or be insanely slow. I wasn't actually thinking a copy would be created, but rather self would be returned after being mutated (rather than None). >> Maybe rescale_row and rescale_col should retain their current >> semantics, and we should have new methods with_rescaled_row and >> with_rescaled_col that always return a modified copy and never modify >> the original. Then rescale_row and rescale_col could catch the type >> error from #3212, and produce a new type error that says something >> like "rescale_row cannot change the base ring of the matrix; try >> with_rescaled_row instead". >> > > +1 -- that's a great idea! Another +1, this is the best solution I've heard so far. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Jun 2, 2008, at 9:47 AM, William Stein wrote: > On Mon, Jun 2, 2008 at 9:45 AM, Carl Witty <[EMAIL PROTECTED]> > wrote: >> >> On Jun 2, 9:17 am, "William Stein" <[EMAIL PROTECTED]> wrote: >>> On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann But back to SymbolicRing and SymbolicConstant. I have the following improvement SUGGESTION: when creating sqrt(2) or other roots from integers, then assign to them the parent AlgebraicReal or AlgebraicNumer accordingly instead of the too general Symbolic Ring. >>> >>> That's definitely planned. >> >> Actually, if you mean that sqrt(2) should become the same as >> AA(sqrt(2)) is now, I'm not sure that's a good idea, for two reasons. >> First, AA and QQbar by design don't maintain enough information to >> print nicely. (This could be improved somewhat from the current >> state, but not enough to compete with symbolic radical expressions.) >> Second, since AA and QQbar incorporate complete decision procedures, >> it is easy to construct examples where they are very, very slow; I >> think people would often be happier with the less complete but much >> faster techniques used in symbolics. > > I think the plan is that algebraic elements won't just be generic > symbolic > elements, e.g., sqrt(2) would be a generator for ZZ[sqrt(2)]. This > has > been discussed a few times.I didn't mean that using AA or QQbar > by default was precisely what is planned. Yep. Specifically, the plan is for sqrt(2) to become an element of ZZ [sqrt(2)] *with* and embedding into RR (so stuff like RR(sqrt(2)) or even 1.123 + sqrt(2) works). We would want to use very nice AA/QQbar code to compute, say, sqrt(2) + sqrt(3) (the result would live in a specific number field with embedding). (Nice) number fields with embedding would coerce into SR. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
Hi, just some short comments by me, since I'm responsible ;) On Jun 2, 7:58 pm, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > On May 31, 2008, at 8:45 AM, Andrey Novoseltsev wrote: > Also, I think it might be better for the text to be left- > justified (but still centered in the page). Yeahr, well, HTML is a bit limited to do layouts and to stay simple and maintainable at the same time. Since the rest of the page is centered, I am for centering the text above, too. This would break it ... About the requested line-break, yes, I've already told others about this and that it doesn't look so good. Also keep in mind, that you have already looked at that page over and over again in different versions. So, you are biased. Try to think as someone who sees the page the first time. This means, that some parts focus your attention that don't focus yours now! > Perhaps it would look better if the label was vertically centered on > the graphic (or at least more so) rather than the sub-label being > centered there. Sorry ,but what exactly do you mean? The current menu is probably the most simplistic one I could imagine. The only important point is, that the sub-menu needs a smaller font than the menu and stays below. The alignment itself works well (in all browsers) and everybody understands how it works... > > > 3) The top and bottom of "Download and Media" header on the download > > page are cut in Firefox under WinXP with large fonts on. ... > > How hard would it be to sort these by platform (according to browser > information?). [...] Right now the Windows download is > the only thing I see (have to scroll down for other options). I have collected some ideas from other pages and I think i know how to do this. The important point I still want to maintain is the ability to download for all platforms. So, just preselecting, but no pre- censoring! But can we just leave it for now until the page is finally online? Once it is clear how the prebuilt binaries will work out, I'll start working on that page to keep it shorter, include more about the binaries and DVD > I think > the blurb could be shorter too (just say a native port is in the works). If you know a better formulation, could you email it me? > > 8) Maybe emphasize in "DVD" section that one can freely make extra > > copies of the bought DVD and use on as many machines as desired? > > +1 ok > > > 9) It is also not very clear what exactly is "Sage on DVD" - source > > code, binaries, "live DVD," all of it? It is explained on the order > > page, but can be added to the site as well, I think. > > Good point. For the record, it's source + binaries for OS X/VMware/ > linux + documentation. It's mostly for people with limited bandwidth > or who like to hold a physical DVD, provided at cost (zero revenue > for us). thx ;) h --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: quantitative finance in sage
On Jun 2, 7:46 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > Hi, > > I've posted a first very very (very) minimal "quantitative finance" > piece of code here: I have briefly looked at the code and I'm curious: How significant is the speed difference between R, using an ts() object and fSeries, and Python? And how does it relate to the finance packages in R? Do you want to implement something similar to rmetrics.org or is this different/more general? h --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: quantitative finance in sage
On Mon, Jun 2, 2008 at 12:02 PM, Harald Schilly <[EMAIL PROTECTED]> wrote: > > > > On Jun 2, 7:46 pm, "William Stein" <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I've posted a first very very (very) minimal "quantitative finance" >> piece of code here: > > I have briefly looked at the code and I'm curious: How significant is > the speed difference between R, using an ts() object and fSeries, and > Python? One sample benchmark I tried was computing the standard deviation. The new code I just wrote was 500 times faster than rpy (and that's *without* considering any communications overhead), and 15 times faster than numpy. Every single function in the time series class that has the same functionality as R or numpy/scipy is significantly faster than those systems -- sometimes not nearly 15 times faster, but often 5 times. I was *really* surprised by how a few hours with cython could do much better than R (and numpy in some cases) for very basic things. If the speed factor were "only" 5 over R, then I still think it would be fully worth redoing everything. That the speed difference is much larger is truly shocking. > And how does it relate to the finance packages in R? Do you > want to implement something similar to rmetrics.org or is this > different/more general? Different and probably less general. The focus is on being blazingly fast and doing a few things very well. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] vfplot
For who is interested: http://sview01.wiredworkplace.net/pub/vfplot/ Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
On Jun 2, 2008, at 11:44 AM, Harald Schilly wrote: > Hi, just some short comments by me, since I'm responsible ;) > > On Jun 2, 7:58 pm, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: >> On May 31, 2008, at 8:45 AM, Andrey Novoseltsev wrote: >> Also, I think it might be better for the text to be left- >> justified (but still centered in the page). > > Yeahr, well, HTML is a bit limited to do layouts and to stay simple > and maintainable at the same time. Since the rest of the page is > centered, I am for centering the text above, too. This would break > it ... > About the requested line-break, yes, I've already told others about > this and that it doesn't look so good. Also keep in mind, that you > have already looked at that page over and over again in different > versions. So, you are biased. Try to think as someone who sees the > page the first time. This means, that some parts focus your attention > that don't focus yours now! Very true. And don't hesitate to let me know if I'm giving too much feedback :-). >> Perhaps it would look better if the label was vertically centered on >> the graphic (or at least more so) rather than the sub-label being >> centered there. > > Sorry ,but what exactly do you mean? The current menu is probably the > most simplistic one I could imagine. The only important point is, that > the sub-menu needs a smaller font than the menu and stays below. The > alignment itself works well (in all browsers) and everybody > understands how it works... Sorry, I was talking about the buttons (which I really like, BTW). Just a minor tweak: >>> 3) The top and bottom of "Download and Media" header on the download >>> page are cut in Firefox under WinXP with large fonts on. > ... >> >> How hard would it be to sort these by platform (according to browser >> information?). [...] Right now the Windows download is >> the only thing I see (have to scroll down for other options). > > I have collected some ideas from other pages and I think i know how to > do this. The important point I still want to maintain is the ability > to download for all platforms. So, just preselecting, but no pre- > censoring! For sure. > But can we just leave it for now until the page is finally online? Probably best to test it out before the site goes live, but if it's going to be a lot of work than it's not worth holding things back for. > Once it is clear how the prebuilt binaries will work out, I'll start > working on that page to keep it shorter, include more about the > binaries and DVD > >> I think >> the blurb could be shorter too (just say a native port is in the >> works). > > If you know a better formulation, could you email it me? Just trimming it down a bit, how about: "Sage depends on many components which are not yet available for Microsoft Windows. A native port is in the works. The current VMWare Image provides you with an encapsulated and solid tested system and contains everything and needs nearly no configuration." >>> 8) Maybe emphasize in "DVD" section that one can freely make extra >>> copies of the bought DVD and use on as many machines as desired? >> >> +1 > > ok > >> >>> 9) It is also not very clear what exactly is "Sage on DVD" - source >>> code, binaries, "live DVD," all of it? It is explained on the order >>> page, but can be added to the site as well, I think. >> >> Good point. For the record, it's source + binaries for OS X/VMware/ >> linux + documentation. It's mostly for people with limited bandwidth >> or who like to hold a physical DVD, provided at cost (zero revenue >> for us). > > thx ;) One more comment (on content), the I like breaking up the "Feature tour," but the research section should probably be highly re-written to be a bit more high-level. (E.g. mention all the fields it covers: Number Theory, Combinatorics, Numerics, Linear Algebra, ...) - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: log vs log_b
We could easily change this so that we by default go ahead and coerce the log(10) to RR if its multiplied by something in RR. (so that we end up with a numeric result). This is probably a good idea. On Mon, Jun 2, 2008 at 12:05 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > > On Jun 1, 2008, at 2:13 AM, Martin Albrecht wrote: > >> >>> I didn't even know there was a log_b, so I would be *very* happy >>> to delete it. >>> >>> -- William >> >> They are not the same: >> >> sage: log_b(10,2) >> 3.32192809489 >> sage: log(10,2) >> log(10)/log(2) >> >> but log(10,2).n() is. > > I don't think we need a separate log_b command for that. However, > this has always annoyed me: > > sage: log(10.0,2) > 3.32192809488736 > sage: log(10,2.0) > 1.44269504088896*log(10) > > - Robert > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish <[EMAIL PROTECTED]> wrote: > > -1. First, everything cwitty said is correct. Second, if we start > using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going > through the coercion system which was designed to be elegant instead > of fast, so this becomes insanely slow for any serious use. Finally, > this is going to require serious code duplication from symbolics, so > I'm not sure what the big gain is over just using symbolics to do this > in the first place. Also, cwitty pointed out that sage: sum([sqrt(p) for p in prime_range(1000)]) works fine in Sage now, but with your (and my) proposal, it would be impossible, since it would require constructing a ring of integers of a number field of degree 2^168.. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
On Mon, Jun 2, 2008 at 12:13 PM, Jaap Spies <[EMAIL PROTECTED]> wrote: > > For who is interested: > > http://sview01.wiredworkplace.net/pub/vfplot/ > What is it? Have *you* tried it? Did you like it or not? How do you think it might be relevant to Sage? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
-1. First, everything cwitty said is correct. Second, if we start using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going through the coercion system which was designed to be elegant instead of fast, so this becomes insanely slow for any serious use. Finally, this is going to require serious code duplication from symbolics, so I'm not sure what the big gain is over just using symbolics to do this in the first place. On Mon, Jun 2, 2008 at 12:31 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > On Jun 2, 2008, at 9:47 AM, William Stein wrote: > >> On Mon, Jun 2, 2008 at 9:45 AM, Carl Witty <[EMAIL PROTECTED]> >> wrote: >>> >>> On Jun 2, 9:17 am, "William Stein" <[EMAIL PROTECTED]> wrote: On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann > But back to SymbolicRing and SymbolicConstant. > I have the following improvement > SUGGESTION: when creating sqrt(2) or other roots from integers, > then > assign to them the parent AlgebraicReal or AlgebraicNumer > accordingly > instead of the too general Symbolic Ring. That's definitely planned. >>> >>> Actually, if you mean that sqrt(2) should become the same as >>> AA(sqrt(2)) is now, I'm not sure that's a good idea, for two reasons. >>> First, AA and QQbar by design don't maintain enough information to >>> print nicely. (This could be improved somewhat from the current >>> state, but not enough to compete with symbolic radical expressions.) >>> Second, since AA and QQbar incorporate complete decision procedures, >>> it is easy to construct examples where they are very, very slow; I >>> think people would often be happier with the less complete but much >>> faster techniques used in symbolics. >> >> I think the plan is that algebraic elements won't just be generic >> symbolic >> elements, e.g., sqrt(2) would be a generator for ZZ[sqrt(2)]. This >> has >> been discussed a few times.I didn't mean that using AA or QQbar >> by default was precisely what is planned. > > > Yep. Specifically, the plan is for sqrt(2) to become an element of ZZ > [sqrt(2)] *with* and embedding into RR (so stuff like RR(sqrt(2)) or > even 1.123 + sqrt(2) works). We would want to use very nice AA/QQbar > code to compute, say, sqrt(2) + sqrt(3) (the result would live in a > specific number field with embedding). (Nice) number fields with > embedding would coerce into SR. > > - Robert > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
William Stein wrote: > On Mon, Jun 2, 2008 at 12:13 PM, Jaap Spies <[EMAIL PROTECTED]> wrote: >> For who is interested: >> >> http://sview01.wiredworkplace.net/pub/vfplot/ >> > > What is it? Have *you* tried it? Did you like it or not? How do you think > it might be relevant to Sage? > No, I did not try it, but somehow I liked the curved arrows :) Maybe someone who is interested in vectorfield plots can investigate. Jaap > William > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Improving rescaling of matrices
> > >> Maybe rescale_row and rescale_col should retain their current > >> semantics, and we should have new methods with_rescaled_row and > >> with_rescaled_col that always return a modified copy and never modify > >> the original. Then rescale_row and rescale_col could catch the type > >> error from #3212, and produce a new type error that says something > >> like "rescale_row cannot change the base ring of the matrix; try > >> with_rescaled_row instead". > > > +1 -- that's a great idea! > > Another +1, this is the best solution I've heard so far. > > - Robert Unless someone continues this thread, I will assume that this idea carries the day in finishing work on this ticket (which may now take a bit longer). Thanks very much for the input. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi William, William Stein wrote: | That said I really *really* want a full native version of Sage on Windows... I've been wondering about this for a while. Are you referring specifically to MSVC support or "it gets compiled natively under windows" (i.e., MinGW or Intel...)? In other words, are you going specifically for Microsoft's compilers' support and, if so, what is the reason behind this decision? Best regards, ~ Francesco. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhEYfwACgkQFCtI0YdDCEvJ8gCgu8SrT3nC9ERy6mhQ6cFJ60te kaUAoMMAL3QpVMlziT4xe5G5jLX5D/ik =8n3c -END PGP SIGNATURE- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
On Jun 2, 11:11 pm, Francesco Biscani <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi William, Hi Francesco, > William Stein wrote: > > | That said I really *really* want a full native version of Sage on > Windows... > > I've been wondering about this for a while. Are you referring > specifically to MSVC support or "it gets compiled natively under > windows" (i.e., MinGW or Intel...)? At the moment: yes. > In other words, are you going > specifically for Microsoft's compilers' support and, if so, what is the > reason behind this decision? For 32 bits we are fixing the Cygwin issues and one goal for Dev1 [starting in a little less than two weeks] is to get that port up and working again. MinGW's support for Python is allegedly problematic, at least during the 2.4 release of python. I have not tried Python 2.5+MinGW. Right now Windows Python 2.5 is build per default with MSVC 2005 in 32 as well as 64 bit mode. It works perfect with Cygwin in 32 bit mode, but there are some problems related to DLL address space which are solvable. Python 2.6 as well as 3.0 will switch to MSVC 2008 as default compiler. For 64 bit Windows the compilers by Microsoft [C/C++] and Intel [Fortran] are the only technical viable option today. On the 64 bit MinGW front things are changing, but I don't expect that compiler to work well this year and we want to be done with the port this year, hopefully by the fall. Once MinGW catches up we are more than happy to support that compiler assuming we don't run into any showstoppers that we cannot fix. For the Intel compilers: I am planning to add support for at least Linux/Itanium, so the Intel compiler on Linux ought to work at some point. The Intel compiler on Windows behaves differently than the Linux version since the Linux version is supposed to be gcc compatible while the Windows version is supposed to be a drop in replacement for MSVC. So once we have MSVC working I will surely see how far I get with the Intel compiler on Windows, too. In the we are willing to support any reasonable compiler, i.e. I am adding Sun Forte support on Solaris at the moment, and obviously welcome fixes from other platforms assuming they don't break the other builds. > Best regards, > > ~ Francesco. Cheers, Michael > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org > > iEYEARECAAYFAkhEYfwACgkQFCtI0YdDCEvJ8gCgu8SrT3nC9ERy6mhQ6cFJ60te > kaUAoMMAL3QpVMlziT4xe5G5jLX5D/ik > =8n3c > -END PGP SIGNATURE- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
On May 14, 12:11 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On Tue, May 13, 2008 at 8:50 PM, Andrey Novoseltsev <[EMAIL PROTECTED]> wrote: > > > 1) I think that completely white background would be the best. > > I would love to see what this looks like. Using the Web Developer extension for FF makes this easy. It looks a bit cleaner, indeed. Regarding the general commentary about the iconography/UI, I think it's definitely on its way. I wonder if something along the lines of RapidWeaver's page (http://www.realmacsoftware.com/rapidweaver/) wouldn't be useful. (I only point to that page because (a) I recently visited it and (b) many third-party Mac pages follow a similar layout scheme). Each of the icons (which I like) might better go with a short, punchy description of that part of the site. Further, to highlight the download (or maybe the online Sage notebook), that item's icon and description grouping might have a subtle background color and/or border. Not anything garish, but something that points interest to it. As to the color scheme itself, dropping to an all-white background helps readability, but I think there's room for the use of color to separate the header from the body. All of that said, I think the new site is a very nice improvement. I am more than happy to contribute to CSS or other stuff if help is needed. When I have a bit more time, I may also more thoroughly comment on the copy and provide suggestions. Daniel Black --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, mabshoff wrote: | For 32 bits we are fixing the Cygwin issues and one goal for Dev1 | [starting in a little less than two weeks] is to get that port up and | working again. MinGW's support for Python is allegedly problematic, at | least during the 2.4 release of python. I have not tried Python | 2.5+MinGW. Right now Windows Python 2.5 is build per default with | MSVC 2005 in 32 as well as 64 bit mode. It works perfect with Cygwin | in 32 bit mode, but there are some problems related to DLL address | space which are solvable. Python 2.6 as well as 3.0 will switch to | MSVC 2008 as default compiler. | | For 64 bit Windows the compilers by Microsoft [C/C++] and Intel | [Fortran] are the only technical viable option today. On the 64 bit | MinGW front things are changing, but I don't expect that compiler to | work well this year and we want to be done with the port this year, | hopefully by the fall. Once MinGW catches up we are more than happy to | support that compiler assuming we don't run into any showstoppers that | we cannot fix. | | For the Intel compilers: I am planning to add support for at least | Linux/Itanium, so the Intel compiler on Linux ought to work at some | point. The Intel compiler on Windows behaves differently than the | Linux version since the Linux version is supposed to be gcc compatible | while the Windows version is supposed to be a drop in replacement for | MSVC. So once we have MSVC working I will surely see how far I get | with the Intel compiler on Windows, too. | | In the we are willing to support any reasonable compiler, i.e. I am | adding Sun Forte support on Solaris at the moment, and obviously | welcome fixes from other platforms assuming they don't break the | other builds. Thanks for the info. I had no idea about the status of 64-bit MinGW, so I understand better your desire to support MSVC. A couple of technical questions: 1) how do you cope with mixed C/C++ - Fortran builds under Windows, given that, AFAIK, it is generally not possible to mix these languages using different compilers (and that Microsoft does not provide a Fortran compiler)? 2) more generally, I think that such an effort must undergo tight coordination with upstream. Given that AFAICT most open-source mathematical software is developed on the GCC toolchain, how do you cope with upstream projects using compiler/standard library features present only in GCC? I'm thinking mainly about stuff like assembly support, but also modern C++ standard library features. What do you do if, let's say, Singular starts using TR1's features implemented in GCC but not in MSVC? (in such case the solution could be using Boost's TR1 wrapper, but this requires notable interaction and coordination with the Singular devs) Thanks and best regards, ~ Francesco. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhEa2AACgkQFCtI0YdDCEuPrACeNBqnPZS0a0KAw0xsRGSDbHxk P2sAn2yzALjWeMQjdHeTgNvXYPS/7Yza =rap4 -END PGP SIGNATURE- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
2008/6/2 William Stein <[EMAIL PROTECTED]>: > > On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish <[EMAIL PROTECTED]> wrote: >> >> -1. First, everything cwitty said is correct. Second, if we start >> using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going >> through the coercion system which was designed to be elegant instead >> of fast, so this becomes insanely slow for any serious use. Finally, >> this is going to require serious code duplication from symbolics, so >> I'm not sure what the big gain is over just using symbolics to do this >> in the first place. > > Also, cwitty pointed out that > > sage: sum([sqrt(p) for p in prime_range(1000)]) > > works fine in Sage now, but with your (and my) proposal, > it would be impossible, since it would require constructing > a ring of integers of a number field of degree 2^168.. Surely that is something which we can train users not to do? I remember years ago learning the difference in pari/gp between sum(n=1,1000,1/n) and sum(n=1,1000,1.0/n) and it's a lesson which only needs to be learnt once. On the other hand pari/gp always has assumed a lot of its users, and Sage has aspirations to be easy to use too... John > > -- William > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: quantitative finance in sage
There is a free library for quantitaive finance called quantlib http://quantlib.org/ The library is writen in C++ but comes with python bindings. The licence is modified BSD (http://quantlib.org/license.shtml) (wich is GPL-compatible) Perhaps you might want to integrate it into sage The more serious drawback that I've found (in the little things that I've tried to do with it.) is that the documentation used to be not complete enough and up to date. best regards, Pablo El Monday 02 June 2008 14:46:31 William Stein escribió: > Hi, > > I've posted a first very very (very) minimal "quantitative finance" > piece of code here: > > http://trac.sagemath.org/sage_trac/ticket/3346 > > I hope somebody who has some interest in this area will referee it. > > -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Sage website
On Jun 2, 11:51 pm, Francesco Biscani <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Michael, Hi Francesco, > mabshoff wrote: > > | For 32 bits we are fixing the Cygwin issues and one goal for Dev1 > | [starting in a little less than two weeks] is to get that port up and > | working again. MinGW's support for Python is allegedly problematic, at > | least during the 2.4 release of python. I have not tried Python > | 2.5+MinGW. Right now Windows Python 2.5 is build per default with > | MSVC 2005 in 32 as well as 64 bit mode. It works perfect with Cygwin > | in 32 bit mode, but there are some problems related to DLL address > | space which are solvable. Python 2.6 as well as 3.0 will switch to > | MSVC 2008 as default compiler. > | > | For 64 bit Windows the compilers by Microsoft [C/C++] and Intel > | [Fortran] are the only technical viable option today. On the 64 bit > | MinGW front things are changing, but I don't expect that compiler to > | work well this year and we want to be done with the port this year, > | hopefully by the fall. Once MinGW catches up we are more than happy to > | support that compiler assuming we don't run into any showstoppers that > | we cannot fix. > | > | For the Intel compilers: I am planning to add support for at least > | Linux/Itanium, so the Intel compiler on Linux ought to work at some > | point. The Intel compiler on Windows behaves differently than the > | Linux version since the Linux version is supposed to be gcc compatible > | while the Windows version is supposed to be a drop in replacement for > | MSVC. So once we have MSVC working I will surely see how far I get > | with the Intel compiler on Windows, too. > | > | In the we are willing to support any reasonable compiler, i.e. I am > | adding Sun Forte support on Solaris at the moment, and obviously > | welcome fixes from other platforms assuming they don't break the > | other builds. > > Thanks for the info. I had no idea about the status of 64-bit MinGW, so > I understand better your desire to support MSVC. Some people are currently building Firefox with that toolchain which is based on gcc 4.4 IIRC [otherwise it is gcc 4.3], so there is definitely progress being made. Unfortunately it is currently only two people with one of them doing the vast majority of the work, so let's hope it gets all merged back into the official MinGW project soon. I am not 100% clear on why, but the 64 bit effort seems to be something that did not happen within the MinGW project. > A couple of technical questions: > > 1) how do you cope with mixed C/C++ - Fortran builds under Windows, > given that, AFAIK, it is generally not possible to mix these languages > using different compilers (and that Microsoft does not provide a Fortran > compiler)? Fortran code build with the Intel compiler works flawless when linked against MSVC code. I consider it so ironic that on Windows linking C code with Fortran libraries "just works" while on Linux it can be and often is a nightmare, especially once you start mixing and matching. > 2) more generally, I think that such an effort must undergo tight > coordination with upstream. Yep. > Given that AFAICT most open-source > mathematical software is developed on the GCC toolchain, how do you cope > with upstream projects using compiler/standard library features present > only in GCC? I'm thinking mainly about stuff like assembly support, but > also modern C++ standard library features. What do you do if, let's say, > Singular starts using TR1's features implemented in GCC but not in MSVC? > (in such case the solution could be using Boost's TR1 wrapper, but this > requires notable interaction and coordination with the Singular devs) There are three big C++ projects that will be difficult: * Singular: upstream is aware of the project and willing to cooperate. Singular itself uses its own macro based template system since it was written before templates became standard. * LinBox: too many templates ;) - but all kidding aside the LinBox team is very happy to help us out and also integrate the fixes upstream * PolyBoRi: I didn't look too closely at this code base yet, but they use some boost bits, which already should compile with MSVC. But I am not so sure it will be trivial, so it is in my "difficult pile" until proven innocent. The PolyBoRi people are also not exactly saddened that we will port their code to MSVC. If any of the above code or something else not listed here does not compile with MSVC I am willing to try it with the Intel C++ compiler, too. The Windows build of Sage, specifically the 64 bit build will require commercial compilers anyway until the MinGW 64 bit port works. Should bits of the fixes of our fixes be too invasive for upstream we just have to carry a couple of patches and hope that down the road we do find a better solution. I did some analysis of the work we would need to do, so check out http://wiki.sagemath.org/windows/gen
[sage-devel] Re: coercing of log(2)*1.0
On Mon, Jun 2, 2008 at 3:19 PM, John Cremona <[EMAIL PROTECTED]> wrote: > > 2008/6/2 William Stein <[EMAIL PROTECTED]>: >> >> On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish <[EMAIL PROTECTED]> wrote: >>> >>> -1. First, everything cwitty said is correct. Second, if we start >>> using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going >>> through the coercion system which was designed to be elegant instead >>> of fast, so this becomes insanely slow for any serious use. Finally, >>> this is going to require serious code duplication from symbolics, so >>> I'm not sure what the big gain is over just using symbolics to do this >>> in the first place. >> >> Also, cwitty pointed out that >> >> sage: sum([sqrt(p) for p in prime_range(1000)]) >> >> works fine in Sage now, but with your (and my) proposal, >> it would be impossible, since it would require constructing >> a ring of integers of a number field of degree 2^168.. > > Surely that is something which we can train users not to do? Why? Doing that sum works fine now. It's even fun. That all the following work fine even with our current system says something... sage: a = sum([sqrt(p) for p in primes(1000)]) sage: float(a) 3307.7690992952139 sage: RDF(a) 3307.7690993 sage: RealField(1000)(a) 3307.76909929521532337080828563375122663883932558794796752652934831207623440969500409157102585876606649295101934045235119416217303162488345812238151772485033866010535293142064829106852999118135254502207045010375309268967623016528462090375140033057342943102054036545832373683901618507572426685968323860 > I remember years ago learning the difference in pari/gp between > > sum(n=1,1000,1/n) > > and > > sum(n=1,1000,1.0/n) > > and it's a lesson which only needs to be learnt once. > > On the other hand pari/gp always has assumed a lot of its users, and > Sage has aspirations to be easy to use too... > > John > >> >> -- William >> >> > >> > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote: > Doing that sum works fine now. It's even fun. That > all the following work fine even with our current system > says something... > > sage: a = sum([sqrt(p) for p in primes(1000)]) > sage: float(a) > 3307.7690992952139 > sage: RDF(a) > 3307.7690993 > sage: RealField(1000)(a) > > 3307.76909929521532337080828563375122663883932558794796752652934831207623440969500409157102585876606649295101934045235119416217303162488345812238151772485033866010535293142064829106852999118135254502207045010375309268967623016528462090375140033057342943102054036545832373683901618507572426685968323860 sage: a = e - 1 sage: for i in range(2,100): : a = (a-1)*i : sage: float(a) -1.3491675327339235e+140 sage: RDF(a) -1.34916753273e+140 sage: RealField(1000)(a) 1.0100010191094737330783479071750558784854694330666719781458645331617143268163560343706814329184685328514081778158205141322918688406340340355792675106115099850396387113493402064121653102597587035584599866091432567502680436745983344808432577075043013574712846877319486115708287043275014203343194844 sage: a = e - 1 sage: for i in range(2,200): : a = (a-1)*i : sage: float(a) -inf sage: RealField(100)(a) -5.6297658631950881996939935452e342 sage: RealField(200)(a) 1.1804891378835970579289419600656355595291746689227892615143e312 sage: RealField(1)(a) 1.00502499 -- Gonzalo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
BTW, if I change the iteration limit to 250 or more, I get a : maximum recursion depth exceeded when evaluating float(a)... (sage 3.0) Gonzalo On 6/2/08, Gonzalo Tornaria <[EMAIL PROTECTED]> wrote: > On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote: > > Doing that sum works fine now. It's even fun. That > > all the following work fine even with our current system > > says something... > > > > sage: a = sum([sqrt(p) for p in primes(1000)]) > > sage: float(a) > > 3307.7690992952139 > > sage: RDF(a) > > 3307.7690993 > > sage: RealField(1000)(a) > > > 3307.76909929521532337080828563375122663883932558794796752652934831207623440969500409157102585876606649295101934045235119416217303162488345812238151772485033866010535293142064829106852999118135254502207045010375309268967623016528462090375140033057342943102054036545832373683901618507572426685968323860 > > > > sage: a = e - 1 > sage: for i in range(2,100): > : a = (a-1)*i > : > sage: float(a) > -1.3491675327339235e+140 > sage: RDF(a) > -1.34916753273e+140 > sage: RealField(1000)(a) > > 1.0100010191094737330783479071750558784854694330666719781458645331617143268163560343706814329184685328514081778158205141322918688406340340355792675106115099850396387113493402064121653102597587035584599866091432567502680436745983344808432577075043013574712846877319486115708287043275014203343194844 > > sage: a = e - 1 > sage: for i in range(2,200): > : a = (a-1)*i > : > sage: float(a) > -inf > sage: RealField(100)(a) > -5.6297658631950881996939935452e342 > sage: RealField(200)(a) > 1.1804891378835970579289419600656355595291746689227892615143e312 > sage: RealField(1)(a) > 1.00502499 > > -- > > Gonzalo > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Mon, Jun 2, 2008 at 5:15 PM, Gonzalo Tornaria <[EMAIL PROTECTED]> wrote: > > On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote: >> Doing that sum works fine now. It's even fun. That >> all the following work fine even with our current system >> says something... >> >> sage: a = sum([sqrt(p) for p in primes(1000)]) >> sage: float(a) >> 3307.7690992952139 >> sage: RDF(a) >> 3307.7690993 >> sage: RealField(1000)(a) >> >> 3307.76909929521532337080828563375122663883932558794796752652934831207623440969500409157102585876606649295101934045235119416217303162488345812238151772485033866010535293142064829106852999118135254502207045010375309268967623016528462090375140033057342943102054036545832373683901618507572426685968323860 > > > sage: a = e - 1 > sage: for i in range(2,100): > : a = (a-1)*i > : > sage: float(a) > -1.3491675327339235e+140 > sage: RDF(a) > -1.34916753273e+140 > sage: RealField(1000)(a) > 1.0100010191094737330783479071750558784854694330666719781458645331617143268163560343706814329184685328514081778158205141322918688406340340355792675106115099850396387113493402064121653102597587035584599866091432567502680436745983344808432577075043013574712846877319486115708287043275014203343194844 > > sage: a = e - 1 > sage: for i in range(2,200): > : a = (a-1)*i > : > sage: float(a) > -inf > sage: RealField(100)(a) > -5.6297658631950881996939935452e342 > sage: RealField(200)(a) > 1.1804891378835970579289419600656355595291746689227892615143e312 > sage: RealField(1)(a) > 1.00502499 > Oh my god, floating point numbers are just broken! Seriously, floating point numbers are what they are. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote: > > sage: a = e - 1 > > sage: for i in range(2,200): > > : a = (a-1)*i > > : > > sage: float(a) > > -inf > > > Oh my god, floating point numbers are just broken! > :-) > Seriously, floating point numbers are what they are. Fair enough. The point I tried to make (not claiming anything is broken) is perhaps complemented by the following: sage: expand(a) 3943289336823952517761816069660925311475679888435866316473712666221797249817016714601521420059923119520886060694598194151288213951213185525309633124764149655567314286353816586186984944719612228107258321201270166459320656137141474266387621212037869516201606287027897843301130159520851620311758504293980894639481185194868736000*e - 1071897174864486954588285503555870921932619716096067696207264960258255126471978323450524440466899839207658500331932544667861226996633494584261184287909240040764477816146086242916693761698570280114717675450768603229802676321234497467428555982733907104528850484797214679822706672415691688065756374587435109932151999457607946738407969860677357914214979720210208723664522819 This is a particular symbolic expression, which has a particular value in RR, whose best approximation in RDF is far from -inf or sage: RDF(expand(a)) nan The "philosophical" question is whether: sage: RDF(A*e - B) (where A*e is damn close to B+1) should be evaluated as sage: RDF(A)*RDF(e) - RDF(B) which is definitely nan since RDF(A) == RDF(B) == +inf. What I mean is, the symbolic expression has (in principle) enough information to figure out that RDF(A*e-B) is close to 1. Whether it is reasonable to expect that is the question. Best, Gonzalo PS: for the record, this seems to be "broken" in the same way in mathematica, for one. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] [sage-devel] Re: Maxima license "GPL v.3 or later"?
On 6/1/08, Andrej Vodopivec <[EMAIL PROTECTED]> wrote: > As I have mentioned in some other thread, even if most of the code is > GPLv2+, there are files which are GPLv2 only: Yeah -- some of those are files which I created. I am willing to change those from GPL v2 to GPL nonspecific. About the others, I guess we will have to identify them and negotiate with each author. I've been meaning for a long time to do a license review sweep through all of the share stuff --- maybe now is as good a time as any. best Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] [sage-devel] Re: Maxima license "GPL v.3 or later"?
On Mon, Jun 2, 2008 at 8:15 PM, Robert Dodier <[EMAIL PROTECTED]> wrote: > > On 6/1/08, Andrej Vodopivec <[EMAIL PROTECTED]> wrote: > >> As I have mentioned in some other thread, even if most of the code is >> GPLv2+, there are files which are GPLv2 only: > > Yeah -- some of those are files which I created. > I am willing to change those from GPL v2 to GPL nonspecific. > About the others, I guess we will have to identify them and > negotiate with each author. I've been meaning for a long time > to do a license review sweep through all of the share stuff --- > maybe now is as good a time as any. Please do. I did precisely this with Sage last year and it wasn't quite as hard as you might think. I got around 40 emails from people specifically giving me permission to change license statements on their files.A lot of the coding and maintenance work you do on Maxima is more difficult than this. Many thanks for following this up. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Trying to extend Integer
On Mon, Jun 2, 2008 at 9:51 PM, Igor Tolkov <[EMAIL PROTECTED]> wrote:
>
> I am trying to extend the integer class:
>
> {{
> class Quple(Integer):
>def __init__(self, a, b):
>Integer.__init__(self, b)
>self.tup = (a, b)
>
> print Quple(3,1)
> ///
>
> 0
> }}}
>
> I should get "1". I stared at this code for too long already.
You can't (and almost certainly shouldn't want to)
extend the builtin rather sophisticated (and
highly optimized) Sage integer class in pure Python.
You should either:
(1) extend Python's int
or
(2) make an object that has an integer as an attribute.
The problem is basically that __new__ and __init__
are very optimized and probably supporting deriving
from the Sage Integer class would slow them down.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Trying to extend Integer
On Mon, Jun 2, 2008 at 10:15 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 2, 2008, at 9:51 PM, Igor Tolkov wrote:
>
>> I am trying to extend the integer class:
>>
>> {{
>> class Quple(Integer):
>> def __init__(self, a, b):
>> Integer.__init__(self, b)
>> self.tup = (a, b)
>>
>> print Quple(3,1)
>> ///
>>
>> 0
>> }}}
>>
>> I should get "1". I stared at this code for too long already.
>
> What are you trying to accomplish? In this case it could probably be
> done an easier way because the Integer class has lots of hacks to
> make it faster which may break extending it with a normal Python class.
>
> - Robert
Hi Robert,
I just noticed this evil property of Sage integers, i.e., they are mutable
no matter what:
sage: n = 5
sage: n.__init__(123)
sage: n
123
Abused this could easily lead to very subtle bugs, like the
one below. Thoughts?
sage: m = matrix(ZZ,2,[1,2,3,4])
sage: d = m.det(); d
-2
sage: d.__init__(389)
sage: m
[1 2]
[3 4]
sage: m.det()
389
The builtin Python integer type does *not* work this way:
sage: n = int(5)
sage: n.__init__(123)
sage: n
5
Bug?
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Trying to extend Integer
On Jun 2, 2008, at 10:18 PM, William Stein wrote:
> On Mon, Jun 2, 2008 at 10:15 PM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>>
>> On Jun 2, 2008, at 9:51 PM, Igor Tolkov wrote:
>>
>>> I am trying to extend the integer class:
>>>
>>> {{
>>> class Quple(Integer):
>>> def __init__(self, a, b):
>>> Integer.__init__(self, b)
>>> self.tup = (a, b)
>>>
>>> print Quple(3,1)
>>> ///
>>>
>>> 0
>>> }}}
>>>
>>> I should get "1". I stared at this code for too long already.
>>
>> What are you trying to accomplish? In this case it could probably be
>> done an easier way because the Integer class has lots of hacks to
>> make it faster which may break extending it with a normal Python
>> class.
>>
>> - Robert
>
> Hi Robert,
>
> I just noticed this evil property of Sage integers, i.e., they are
> mutable
> no matter what:
>
> sage: n = 5
> sage: n.__init__(123)
> sage: n
> 123
>
> Abused this could easily lead to very subtle bugs, like the
> one below. Thoughts?
>
>
> sage: m = matrix(ZZ,2,[1,2,3,4])
> sage: d = m.det(); d
> -2
> sage: d.__init__(389)
> sage: m
>
> [1 2]
> [3 4]
> sage: m.det()
> 389
>
> The builtin Python integer type does *not* work this way:
>
> sage: n = int(5)
> sage: n.__init__(123)
> sage: n
> 5
>
> Bug?
Oh, that's bad... Of course, there's no stopping there:
sage: K. = NumberField(x^2-2)
sage: a.__init__(K, 1/3)
sage: a
1/3
For Integers, I guess we could put more in the __new__ method, but I
think in general it's just something we're going to have to accept.
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Trying to extend Integer
On Mon, Jun 2, 2008 at 10:30 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 2, 2008, at 10:18 PM, William Stein wrote:
>
>> On Mon, Jun 2, 2008 at 10:15 PM, Robert Bradshaw
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On Jun 2, 2008, at 9:51 PM, Igor Tolkov wrote:
>>>
I am trying to extend the integer class:
{{
class Quple(Integer):
def __init__(self, a, b):
Integer.__init__(self, b)
self.tup = (a, b)
print Quple(3,1)
///
0
}}}
I should get "1". I stared at this code for too long already.
>>>
>>> What are you trying to accomplish? In this case it could probably be
>>> done an easier way because the Integer class has lots of hacks to
>>> make it faster which may break extending it with a normal Python
>>> class.
>>>
>>> - Robert
>>
>> Hi Robert,
>>
>> I just noticed this evil property of Sage integers, i.e., they are
>> mutable
>> no matter what:
>>
>> sage: n = 5
>> sage: n.__init__(123)
>> sage: n
>> 123
>>
>> Abused this could easily lead to very subtle bugs, like the
>> one below. Thoughts?
>>
>>
>> sage: m = matrix(ZZ,2,[1,2,3,4])
>> sage: d = m.det(); d
>> -2
>> sage: d.__init__(389)
>> sage: m
>>
>> [1 2]
>> [3 4]
>> sage: m.det()
>> 389
>>
>> The builtin Python integer type does *not* work this way:
>>
>> sage: n = int(5)
>> sage: n.__init__(123)
>> sage: n
>> 5
>>
>> Bug?
>
> Oh, that's bad... Of course, there's no stopping there:
>
> sage: K. = NumberField(x^2-2)
> sage: a.__init__(K, 1/3)
> sage: a
> 1/3
>
> For Integers, I guess we could put more in the __new__ method, but I
> think in general it's just something we're going to have to accept.
Damn, I was really hoping you were not going to say that.
Every cython class has this problem, by the way, as does
every pure Python class for that matter:
sage: class foo:
... def __init__(self, a):
... self.b = a
sage: f = foo(10)
sage: f.b
10
sage: f.__init__(20)
sage: f.b
20
Well Sage hasn't exploded already because of this, so
I guess we'll just have to live with it.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Trying to extend Integer
>sage: class foo: >... def __init__(self, a): >... self.b = a >sage: f = foo(10) >sage: f.b >10 >sage: f.__init__(20) >sage: f.b >20 > >Well Sage hasn't exploded already because of this, so >I guess we'll just have to live with it. Excellent. Now we can inflate integers to match the dollar inflation! Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Jun 2, 2008, at 12:55 PM, William Stein wrote:
> On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish
> <[EMAIL PROTECTED]> wrote:
>>
>> -1. First, everything cwitty said is correct.
More on this below.
>> Second, if we start
>> using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires
>> going
>> through the coercion system which was designed to be elegant instead
>> of fast, so this becomes insanely slow for any serious use.
The coercion system is designed to be elegant *and* fast. Writing
something like 1 + sqrt(2) is going to require the coercion system no
matter what we do, as is 1 + sqrt(2) + 1/2. Computing QQ(sqrt(2), sqrt
(3)) may take a millisecond or two, but after that coercion into it
from ether ring will be fast.
>> Finally, this is going to require serious code duplication from
>> symbolics, so
>> I'm not sure what the big gain is over just using symbolics to do
>> this
>> in the first place.
Number field element work completely differently than symbolics, I
see little if any code duplication.
> Also, cwitty pointed out that
>
> sage: sum([sqrt(p) for p in prime_range(1000)])
>
> works fine in Sage now, but with your (and my) proposal,
> it would be impossible, since it would require constructing
> a ring of integers of a number field of degree 2^168..
This is the biggest argument against such a proposal, and I'm not
quite sure how best to handle this. One would have to implement large
number fields over sparse polynomials, and only lazily compute the
ring of integers. Or, as John Cremona suggested, "train users." None
of the above are ideal.
I would like to give my motivation for not having sqrt(2) be in SR:
1) Speed. I know you're working very hard to make symbolics much,
much faster than they currently are, but I still don't think it'll be
able to compete in this very specialized domain. Currently:
sage: timeit("((1+sqrt(2))^100).expand()")
5 loops, best of 3: 52.9 ms per loop
sage: timeit("((1+sqrt(2)+sqrt(3))^50).expand()")
5 loops, best of 3: 579 ms per loop
sage: sym_a = sqrt(2) + sqrt(3)
sage: timeit("((1+sym_a)^50).expand()")
5 loops, best of 3: 576 ms per loop
Compared to
sage: K. = NumberField(x^2-2)
sage: timeit("((1+a)^100)")
625 loops, best of 3: 48.4 µs per loop
sage: K. = NumberField(x^4 - 10*x^2 + 1)
sage: timeit("((1+a)^50)")
625 loops, best of 3: 138 µs per loop
That's over three orders of magnitude faster (and it's *not* due to
pexpect/interface overhead as the actual input and output are
relatively small). Making arithmetic involving a couple of radicals
fast should probably be the most important, especially as one starts
making structures over them.
2) I personally don't like having to sprinkle the "expand" and and/or
"simplify" all over the place. Now I don't think symbolics should be
expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1
+i). It's like just getting the question back. (I guess I'm revealing
my bias that I don't think of it as living in SR, but rather a number
field...) On that note, I can't even figure out how to do simplify
"(sqrt(2)-3)/(sqrt(2)-1)" in the symbolics...as opposed to
sage: K. = NumberField(x^2-2)
sage: (sqrt2-3)/(sqrt2-1)
-2*sqrt2 - 1
sage: 1/(sqrt2-1)
sqrt2 + 1
3) The coercion system works best when things start as high up the
tree as they can, and the Symbolic Ring is like the big black hole at
the bottom that sucks everything in (and makes it slow). There is a
coercion from ZZ[sqrt(2)] (with embedding) to SR, but not the other
way around, and even trying to cast the other way is problematic. I'd
rather that matrix([1, 1/2, 0, sqrt(2)]) land in a matrix space over
the a number field (rather than over SR), and ZZ['x'].gen() + sqrt(2)
be an actual polynomial in x. Also, the SR, though very useful,
somehow seems less rigorous (I'm sure that this is improving).
Of course many of these are a matter of opinion/taste, but I think
they are worth considering.
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
