Alpha: enter "e^1.1", press "more digits" 3.0041660239464331120584079535886723932826810260162727621297528605...
Sage: RealLazyField()((e^1.1)).numerical_approx(200) 3.0041660239464333947978502692421898245811462402343750000000 Sage is not Wolfram Alpha, and neither is Mathematica. Alpha is trying to get at something different. It would be GREAT if there were an open source natural language processing thing of that type (a few attempts have been made, not necessarily with Sage, if I recall correctly), but to my knowledge there isn't. But that is not Sage's goal. Sage can obviously do this computation: sage: z = e^(11/10) sage: RealField(1000)(z) 3.0041660239464331120584079535886723932826810260162727621297528605... The real issue is that you want 1.1 to be 11/10. I think this is a reasonable thing to talk about, but it's also reasonable to recognize that it's not inherently wrong to tell the software users they aren't the same thing. We have to have some convention (and here, "we" is more than just Sage) for how decimals are interpreted, and the convention for most such software seems to be that it is interpreted as a float of some kind. I'm super careful to tell students the difference between what their calculator says and the fractions they may or may not represent, and that includes with material below that of calculus, and I certainly wouldn't encourage them to treat 1.1 the same as 11/10 in a system beyond a hand-held calculator. 1.1^x is not the same as (11/10)^x in a modeling situation; the latter implies you know the exact growth rate, the former is a model. (I do not tell them about floating-point unless they are computer science majors or are likely to take additional mathematics where this becomes relevant, such as linear algebra.) I strongly doubt I am the only teaching mathematician who does that. Though it seems Dima has a potential approach, maybe we just have to agree to disagree on this. To bring reasonably independent evidence, here is a quote from a book on Sage NOT written by a developer (Gregory Bard's "Sage for Undergraduates"): "The number 0.5 is already a decimal and thus Sage assumes that it is a mere numerical approximation. However, the number 1/2 ... " and (a few paragraphs earlier), "However, if our project becomes an important part in a larger program ... then wasting half the computation time would be exceptionally unwise." That seems appropriate for this level in explaining the issue at hand. This text is intended for high school and (mostly) college educators and their students, and is written by someone with plenty of non-Sage programming, experience, but also plenty of practical teaching experience at an engineering school. I hope it is clear from this example that reasonable people who care about end users can come to different conclusions about whether 1.1 should be treated the same as 11/10, and whether this is (at least in the educational context) something that can be effectively communicated to students. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6e664940-e644-4960-8229-feaca2f99b5an%40googlegroups.com.
