To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GBm-_HXym4fA8qBP4YTYCw%2B3ooO4zXPeU2r%3Dfx%3D90Br%2BA%40mail.gmail.com.
sage: A = matrix([[-3, 2, 1 ],
....: [ 2,-4, 4 ],
....: [ 1, 2,-5 ]])
sage: B = (2 * 0.5 * A)
sage: B == A
True
sage: B.rank() == A.rank()
False
I promise you that I know what a floating point number is, and that
they aren't the problem. The problem is that reasonable expectations
are not met by the Sage user interface.
Here's one:
RealField(200)(2*1.1)
2.2000000000000001776356839400250464677810668945312500000000
Let's check the types:
type(2)
<class 'sage.rings.integer.Integer'>
type(1.1)
<class 'sage.rings.real_mpfr.RealLiteral'>
type(2*1.1)
<class 'sage.rings.real_mpfr.RealNumber'>
sage: m = matrix(Integers(4), 2, [2,2,2,2])
sage: m.rank()
Traceback (most recent call last):
...
NotImplementedError: Echelon form not implemented over 'Ring of integers modulo 4'.
It seems reasonable to me that a similar NotImplementedError could be thrown for generic dense matrices. Is that an acceptable solution @Dima and @Michael? It seems easy enough to add a `.rank()` method in `matrix/matrix_generic_dense.pyx` which throws the error. I'd be happy to make this PR if that is reasonable to folks.
I don't have much understanding of how floating point arithmetic works, but the argument>If you're writing python code, you should expect 2*0.5 to return a>float. But if you're learning linear algebra for the first time and>typing a matrix into the Sage notebook, typing 0.5 instead of 1/2
>should not ruin the entire assignment without so much as a warning.seems important to me. I also sometimes worry that Sage seems to be written for users who are both experts in [insert mathematical field here] and Python. This prevents (a) mathematical experts who don't know python from using Sage and (b) more junior students from using sage. Maybe one can make the argument that mathematical experts should just learn python (although I would disagree), but I think (b) is a genuine problem. Mathematica doesn't seem to require the user to be expert in either math or Wolfram language (or maybe I haven't used it enough). I don't have an actionable complaint here, but it is something I encounter when helping folks around my math department with their code. I'm trying to keep it in mind as I develop code.I see thatsage: A = matrix([[-3, 2, 1 ],[ 2,-4, 4 ], [ 1, 2,-5 ]])
sage: B = (2*0.5*A)sage: rank(B)3What about floating point arithmetic makes this break? I print (B) and see[-3.00000000000000 2.00000000000000 1.00000000000000]
[ 2.00000000000000 -4.00000000000000 4.00000000000000]
[ 1.00000000000000 2.00000000000000 -5.00000000000000]which doesn't have any obvious reason to be not rank-2. Could someone ELI5?
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/cc5a27a3-e855-43e1-a494-b411c613497dn%40googlegroups.com.
It's reasonable to expect that multiplying by one won't cause a viable
alternative to Mathematica et al. to go bonkers. I haven't declared a
float variable, and I haven't type-cast anything to float. The
expression "0.5" is, a priori, quite equal to 1/2. Mathematica knows
it, my old Casio calculator knows it, and in fact, Sage knows it:
sage: 2 * 0.5 == ZZ(1)
True
Awesome, let's talk about floating point semantics. [...]
We zero-pad the 1.1 to whatever length is needed to match the other number.
Because we see 1.1 as a shorthand for 1.1000000000000.... (infinitely many zeros)
That's the ordinary-person semantics of the string "1.1".
It's reasonable to expect that multiplying by one won't cause a viable
alternative to Mathematica et al. to go bonkers. I haven't declared a
float variable, and I haven't type-cast anything to float. The
expression "0.5" is, a priori, quite equal to 1/2. Mathematica knows
it
Wolfram Alpha also has beginners and students as a big chunk of its user base, and they get the default semantics exactly right.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/03e8ce36-52e5-44b3-986d-984c5ae9ef6fn%40googlegroups.com.
Wolfram Alpha also has beginners and students as a big chunk of its user base, and they get the default semantics exactly right.
On Sunday, 16 April 2023 at 14:31:43 UTC-7 aw wrote:Awesome, let's talk about floating point semantics. [...]
We zero-pad the 1.1 to whatever length is needed to match the other number.
Because we see 1.1 as a shorthand for 1.1000000000000.... (infinitely many zeros)
That's the ordinary-person semantics of the string "1.1".That's not floating-point semantics. That's just a funny way of writing 11/10. Those are also not the semantics that scientific calculators use (or excel for that matter), so I suspect that "ordinary persons" are already quite used to 1.1 not meaning an exact rational number but a possible approximation to something quite close to 11/10.
The design decision here to let the multiplication of a "RealLiteral" by a sage integer result in a "RealNumber" is because your use of RealLiteral was taken to signal intent to use floats over exact types. If you wanted exact results you could have used 2*11/10 .
On Sat, 2023-04-15 at 18:20 -0400, David Roe wrote:
My favorite permabug:
sage: A = matrix([[-3, 2, 1 ],
....: [ 2,-4, 4 ],
....: [ 1, 2,-5 ]])
sage: B = (2 * 0.5 * A)
sage: B == A
True
sage: B.rank() == A.rank()
False
Here's what users expect when they type an expression into a higher-precision environment: they expect the answer to be the exact answer, truncated to the precision of that environment. Period. This is not negotiable. There is no latitude for the software to deviate from that.When I type 2*1.1 into an environment with a precision of 200 bits, I expect the answer to be the exact answer truncated to 200 bits, or about 59 digits.
Here's what Sage gives me:RealField(200)(2*1.1)2.2000000000000001776356839400250464677810668945312500000000
And defaults should always be what most users expect (especially when it's 99%+ of users, as it is in the case).
Apologies, typos corrected in code above (note the double star in **kwargs)old_RealNumber=RealNumber
def RealNumber(*args,**kwargs):
return QQ(old_RealNumber(*args,**kwargs))
Guys, this is serious. Any dev who starts reading this, give it a hard look, ok?
Below I give some examples where Sage give the wrong answer, with no error message or any indication that the answer is not correct.
Probably the single most important rule in software is, never ever give users the wrong answer.
Either give them the right answer, or give them no answer along with an error message explaining why the right answer can't be given.
Why the heck is Sage not following this rule?
After finding these examples, it's hard for me to trust any answer I get from Sage, unless I check it against other software, like Wolfram Alpha.
One possible response to my examples below is, I am not using Sage functions in an approved way.
But that's not a valid objection. A user should be able to send any argument to a function, and it's the responsibility of the programmer to make sure one of two things happen:
(a) the user is given the right answer;
or (b) the user is given no answer and an error message.
Sage is failing to do this.
On to the examples.
Example 1, straight from the sage RealField docs:
RealField(120)(RR(13/10))
1.3000000000000000444089209850062616
RR has default 53 bits, so this is really:
RealField(120)(RealField(53)(13/10))
Here's the same thing with less precision to make it clear that this has nothing to do with Python's single or double precision floats:
RealField(18)(RealField(12)(13/10)) (A)
What should happen here is this:
RealField(12) should eval 13/10 as 1.30
RealField(12) should pass to RealField(18) only those digits, 1.30
RealField(18) should then zero-pad that to 18 bits, yielding 1.3000
Here's what sage does:
RealField(18)(RealField(12)(13/10))
1.2998
Let's check the types of all args:
type(13/10)
sage.rings.rational.Rational
type(18) # type(12) is the same
sage.rings.integer.Integer
All args to RealField in (A) are Sage types.
Hence everything in the calculation (A) is under the complete control of Sage.
Hence Sage could easily do the right thing here.
But it doesn't.
You might say, this is an artificial example, passing the output of one RealField to another in a non-sanctioned way.
Ok then, let's just pass arguments to one RealField.
Can we get it to give wrong answers?
Yes, very easily, by passing it an arithmetic expression.
Sending in arithmetic expressions should be totally fine, because the RealField docs say: "This is a binding for the MPFR arbitrary-precision floating point library."
The purpose of MPFR is to be able to do basic arithmetic in arbitrary precision.
Basic arithmetic means any expression using the following ops (and maybe some others): +, -, *, /, ^
So let's pass an arithmetic expression to RealField.
The whole point of MPFR is to always give the right answer for the value of such an expression, for any expression and any requested precision.
The docs say RealField is a binding for MPFR.
So RealField should only give right answers.
But in fact it sometimes gives the wrong answer.
Here's one:
RealField(200)(2*1.1)
2.2000000000000001776356839400250464677810668945312500000000
Let's check the types:
type(2)
<class 'sage.rings.integer.Integer'>
type(1.1)
<class 'sage.rings.real_mpfr.RealLiteral'>
type(2*1.1)
<class 'sage.rings.real_mpfr.RealNumber'>
Here the expression 2*1.1 is not only a Sage type, it's a Sage type designed to work with MPFR. Hence passing 2*1.1 to RealField should yield the right answer.
But it doesn't.
How the heck was this not noticed earlier?
I think I have a workaround for expressions such as 2*1.1: enter the 1.1 as a sage rational, 11/10:
RealField(200)(2*11/10)
2.2000000000000000000000000000000000000000000000000000000000
That works for this expression, but I worry that with other kinds of expression I could still get wrong answers.
By the way, in this example i used numbers where we know the answer in advance, so it's easy to see that the answer given is wrong.
Here's a very similar example where we don't know the answer in advance:
RealField(200)(e^(1.1))
3.0041660239464333947978502692421898245811462402343750000000
RealField(200)(e^(11/10))
3.0041660239464331120584079535886723932826810260162727621298
Wolfram Alpha says the second one is correct.
Let's check the types for the wrong one:
type(e)
<class 'sage.symbolic.constants_c.E'>
type(1.1)
<class 'sage.rings.real_mpfr.RealLiteral'>
type(e^(1.1))
<class 'sage.rings.real_mpfr.RealNumber'>
All are sage types, and the expression as a whole is a sage type designed to work with MPFR. Sage should give the right answer here, but it doesn't.
I like the idea of Sage. And I know the Sage devs must be solid professionals. But giving users junk answers makes Sage look bush-league.
The MPFR devs would never allow their library to give a junk answer.
Wolfram would never allow Mathematica or Alpha to give a junk answer.
Why the heck are the Sage devs allowing Sage to give junk answers?
-aw
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/83acb2d5-5210-4151-b5a1-826cdd6a6d05n%40googlegroups.com.
<class 'sage.rings.real_mpfr.RealNumber'>
type(RR(1.1))
<class 'sage.rings.real_mpfr.RealLiteral'>
Then from the documention at https://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mpfr.html
class sage.rings.real_mpfr.RealLiteral
Bases: RealNumber
Real literals are created in preparsing and provide a way to allow casting into higher precision rings.
Shouldn't RR(11/10) have the same fate?
Emmanuel
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAD0p0K6weXE%3DrWaAcQ_Z-KAWxOKHpw%2BPU946R0UNjjNSZV9ipg%40mail.gmail.com.
Even in the light of the detailed explanations already given, I do find it hard to see how these outputs are so different:sage: RealField(200)(RR(11/10))
1.1000000000000000888178419700125232338905334472656250000000
sage: RealField(200)(RR(1.1))
1.1000000000000000000000000000000000000000000000000000000000You can increase 200 to 1000: the second one gives all zeros (hooray!) while the first one gives those extra digits which are exactly 1/(5 * 2^51). Both RR(11/10) and RR(1.1) have parent Real Field with 53 bits of precision, where they compare equal, but pushing them into RealField(200) gives different results. And the "better" result (all 0s) somes from the input with the literal 1.1, not from the "rational" input 11/10. To me, that is mysterious. Can someone explain?
Real literals are created in preparsing and provide a way to allow casting into higher precision rings.Shouldn't RR(11/10) have the same fate?
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d9bbb936-36ad-4466-9852-712236ec46dfn%40googlegroups.com.
(A), exact vs inexact:
The purpose of a very high precision environment like RealField(200) is to compute with exact quantities - some combination of ints, rationals, exact rationals like sqrt(2), or exact transcendentals like pi.
fixing a typo: it should be "exact irrationals like sqrt(2)"
But you WON'T be computing with exact quantities in RealField(200) unless your number can be expressed as +- an unsigned 200-bit integer times a power of two, so you're very fundamentally using the wrong tool if you're interested in exact computation.
sage: pi200=RealField(200).pi()sage: cos(pi200/13).algdep(8)
64*x^6 - 32*x^5 - 80*x^4 + 32*x^3 + 24*x^2 - 6*x - 1This shows that cos(pi200/13) is remarkably close to satisfying a sextic equation with remarkably small coefficients
If properly implemented, it can emulate exact computation followed by a truncation to finite precision.When I say a very high precision environment is for doing exact computation, I don't mean that it should handling infinite digit strings. I mean that the input-output function for such an environment should be identical to the input-output function of a hypothetical environment that *does* do the full exact computation and then truncates the answer to the requested precision.
In other words, a very high precision environment should emulate an environment that does the full exact computation and truncates the result to finite precision before giving it to the user. And, this emulation should be perfect.
-aw
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a2e8c4ba-5a73-44a4-992b-449e6d24b479n%40googlegroups.com.
So I think a concrete version of Dima's suggestion would be1. Implement a new field that stores elements internally as rationals, printing as decimals to some precision (you could get a higher precision by casting explicitly to RealField(prec), or by using .n(prec)).2. Real literals would land in this field, which would have coercion maps from Z and Q so arithmetic would be exact under the hood.3. Coercion would go to the symbolic ring, so e^1.1 would live in the symbolic ring (rather than RealField(53) where it lives now). For lack of annoyance it should probably still print as a 53-bit decimal, but you could cast it to RealField(200) and it would give the correct result. I guess other transcendental functions (log, trig) would also land in the symbolics.4. Live with the performance implications. As Dima says, you can use RDF if you want fast floating point arithmetic. But it's already the case that the symbolic ring is a performance trap for unwary users, and I'm not sure it's a good idea encouraging more use of it implicitly.
It's certainly reasonable to not call a floating point field "RealField". C and python don't even do that: they call such elements floats. I'm less sure whether such a RealFloats field should be any less prominent than it is now. Plus the whole renaming transition would be super painful.
On Monday, 17 April 2023 at 16:39:01 UTC-7 aw wrote:If properly implemented, it can emulate exact computation followed by a truncation to finite precision.When I say a very high precision environment is for doing exact computation, I don't mean that it should handling infinite digit strings. I mean that the input-output function for such an environment should be identical to the input-output function of a hypothetical environment that *does* do the full exact computation and then truncates the answer to the requested precision.
In other words, a very high precision environment should emulate an environment that does the full exact computation and truncates the result to finite precision before giving it to the user. And, this emulation should be perfect.Unfortunately, not for a fixed precision. If you're working with 200 bits precision, then you cannot express the roots ofx^2-3 and x^2-(3+2^-200) as different floating point numbers. They are too close for that.
Fixed precision floating point is fundamentally unable to do this: the number of real numbers it can represent in the interval [1,2] is bounded (by the set precision), whereas that interval contains infinitely many rational, algebraic, and transcendental real numbers. So there are pairs of numbers in there it won't be able to represent with distinct representations.
On Monday, April 17, 2023 at 6:24:13 PM UTC-6 Nils Bruin wrote:On Monday, 17 April 2023 at 16:39:01 UTC-7 aw wrote:If properly implemented, it can emulate exact computation followed by a truncation to finite precision.When I say a very high precision environment is for doing exact computation, I don't mean that it should handling infinite digit strings. I mean that the input-output function for such an environment should be identical to the input-output function of a hypothetical environment that *does* do the full exact computation and then truncates the answer to the requested precision.
In other words, a very high precision environment should emulate an environment that does the full exact computation and truncates the result to finite precision before giving it to the user. And, this emulation should be perfect.Unfortunately, not for a fixed precision. If you're working with 200 bits precision, then you cannot express the roots ofx^2-3 and x^2-(3+2^-200) as different floating point numbers. They are too close for that.In that case the environment sees the two roots as having the same value, which to 200 bits may be absolutely correct. In that case the environment *is* perfectly emulating an exact calculation truncated or rounded to 200 bits, as it is required to do.
I think your comment here is based on a subtle mistake in thinking about the precision parameter. You're thinking of it as the precision of the internal calculations in the implementation of the environment. In effect, you're assuming a certain kind of implementation, something like a fixed grid of binary fractions. But the environment can use any implementation, not just that one.
For general environments, the right way to think of the precision parameter is, it's the required precision in the output. The internals of the environment are free to work in any precision, including infinite precision. Integer calculations are infinite precision. If the environment internals use only integer math to evaluate an expression and then convert the resulting value to finite precision to serve to the user, the only place the precision parameter was used was for formatting the output. The calculation itself was independent of the precision parameter.
Using infinite precision internally is ideal and should always be preferred. For expressions using only the operations *,/,+,- and only rational arguments, you can treat the rationals as pairs of ints and just do integer math, which is infinite precision.
But for other expressions this isn't possible, eg a non-square integer to the power 1/2. In that case you have to use some kind of series expansion evaluated to only finitely many terms, or some kind of iterated map that converges to the right answer, but you only iterate it a finite number of times. This is working to only finite precision. In effect you choose an internal precision, by choosing the number of terms to evaluate in the expansion, or the number of times to iterate the map. You choose this internal precision to be *higher* than the user's requested precision, so that you can round your internal result to the user's requested precision and it is correct to that precision.On Monday, April 17, 2023 at 6:24:13 PM UTC-6 Nils Bruin wrote:Fixed precision floating point is fundamentally unable to do this: the number of real numbers it can represent in the interval [1,2] is bounded (by the set precision), whereas that interval contains infinitely many rational, algebraic, and transcendental real numbers. So there are pairs of numbers in there it won't be able to represent with distinct representations.For each value of the precision parameter, there are only finitely many distinct numbers that the environment can output. But taking the union over all precision parameters, the environment can output infinitely many numbers - in fact, a dense subset of the rationals, hence a dense subset of the reals.
The fact that this set is dense in the reals is the whole basis for using finite precision strings of digits as arbitrarily good approximations to arbitrary real numbers!
Specify enough digits, and you can approximate a real number as closely as you like.
Set the precision of your environment high enough, and you can approximate exact real quantities as closely as you like.
RealField(200) alone can't do that.
But RealField() can.
And I think it does, except when I pass it an expression with a float literal, because in that case you guys change the literal's value to a 53-bit approximation, and that trashes, for all n>53, the n-bit approximation that RealField(n) is supposed to give us.
-aw
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4c3e87b7-1fbc-46b3-aeb1-8770c17d10c2n%40googlegroups.com.
On Monday, April 17, 2023 at 6:24:13 PM UTC-6 Nils Bruin wrote:On Monday, 17 April 2023 at 16:39:01 UTC-7 aw wrote:If properly implemented, it can emulate exact computation followed by a truncation to finite precision.When I say a very high precision environment is for doing exact computation, I don't mean that it should handling infinite digit strings. I mean that the input-output function for such an environment should be identical to the input-output function of a hypothetical environment that *does* do the full exact computation and then truncates the answer to the requested precision.
In other words, a very high precision environment should emulate an environment that does the full exact computation and truncates the result to finite precision before giving it to the user. And, this emulation should be perfect.Unfortunately, not for a fixed precision. If you're working with 200 bits precision, then you cannot express the roots ofx^2-3 and x^2-(3+2^-200) as different floating point numbers. They are too close for that.In that case the environment sees the two roots as having the same value, which to 200 bits may be absolutely correct. In that case the environment *is* perfectly emulating an exact calculation truncated or rounded to 200 bits, as it is required to do.
I think your comment here is based on a subtle mistake in thinking about the precision parameter. You're thinking of it as the precision of the internal calculations in the implementation of the environment. In effect, you're assuming a certain kind of implementation, something like a fixed grid of binary fractions. But the environment can use any implementation, not just that one.
sage: R=RealLazyField()
sage: a=cos(R.pi()/13)
sage: a.numerical_approx(200)
0.97094181742605202715698227629378922724986510573900358858764
sage: a.numerical_approx(400)
0.970941817426052027156982276293789227249865105739003588587644526477041708760006676932574606408384261554438205497500991925
sage: a.numerical_approx(800)
0.970941817426052027156982276293789227249865105739003588587644526477041708760006676932574606408384261554438205497500991925446304849693046415555347324930136179166290724598721026150846791024698868142304028116956960541355031116767265861274416574
On Tuesday, April 18, 2023 at 1:31:33 PM UTC-6 Nils Bruin wrote:sage: R=RealLazyField()
sage: a=cos(R.pi()/13)
sage: a.numerical_approx(200)
0.97094181742605202715698227629378922724986510573900358858764
sage: a.numerical_approx(400)
0.970941817426052027156982276293789227249865105739003588587644526477041708760006676932574606408384261554438205497500991925
sage: a.numerical_approx(800)
0.970941817426052027156982276293789227249865105739003588587644526477041708760006676932574606408384261554438205497500991925446304849693046415555347324930136179166290724598721026150846791024698868142304028116956960541355031116767265861274416574Nils, eager versus lazy is not the problem.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/99af3f2e-b725-4c78-a5d6-db5f9f5fb98dn%40googlegroups.com.
It is a problem, as e^1.1 cannot be represented exactly, and it is evaluated eagerly. To what precision should it be evaluated? To 200 bits?Then you will complain that you can't get what you want at 400 bits. Etc etc.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c4885432-5b32-46d9-895b-6d7fae260f0bn%40googlegroups.com.
... the user-supplied string "RealLazyField(200)(e^1.1)"...
RealLazyField(e^1.1).numerical_approx(200)
On Tuesday, April 18, 2023 at 3:29:03 PM UTC-6 Dima Pasechnik wrote:It is a problem, as e^1.1 cannot be represented exactly, and it is evaluated eagerly. To what precision should it be evaluated? To 200 bits?Then you will complain that you can't get what you want at 400 bits. Etc etc."1.1" doesn't need to be evaluated, it needs to be replaced by "11/10", in pre-processing.
On Tuesday, April 18, 2023 at 3:29:03 PM UTC-6 Dima Pasechnik wrote:It is a problem, as e^1.1 cannot be represented exactly, and it is evaluated eagerly. To what precision should it be evaluated? To 200 bits?Then you will complain that you can't get what you want at 400 bits. Etc etc."1.1" doesn't need to be evaluated, it needs to be replaced by "11/10", in pre-processing.I don't know the code involved, but I'll take a stab at one way it could be done, something like this: when the Sage interpreter is looking at the user-supplied string "RealLazyField(200)(e^1.1)", it knows that it is about to pass a parse of the string "e^1.1" on to RealLazyField.
In this situation, where the receiver of the parse is RealLazyField, the interpreter can easily change its usual parsing of "1.1". Instead of some kind of float, it can parse it as the exact rational 11/10, and send the resulting parse of the whole expression to RealLazyField for evaluation. To RealLazyField, it's as if the user supplied string was "RealLazyField(200)(e^(11/10))".The details of how this gets done, don't matter.All that matters is that "1.1" gets replaced by "11/10".Do that any way you want.-aw
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c4885432-5b32-46d9-895b-6d7fae260f0bn%40googlegroups.com.
1) compute t=e^1.12) compute RealLazyField(200)(t)When you do step 1), you need, in Python, to set a precision, implicitly or explicitly. (Same in Mathematica, by the way, you can do SetPrecision[...]).
Did you read my message from last night? I highlighted exactly the problems with what you're suggesting.David
---aw
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d489307e-d14b-4ede-a207-e53a5319d65fn%40googlegroups.com.
The present default is to use "1.1" as a designation of a floating point literal, with in implied precision derived from the number of digits used to write down the mantissa.
It may not be the default, but you can still have it! As referenced before, just execute upon startup:old_RealNumber=RealNumber
def RealNumber(*args, **kwargs):
return QQ(old_RealNumber(*args, **kwargs))You can place it in a startup file so that it is in force for all your subsequent sessions. See: https://doc.sagemath.org/html/en/reference/repl/startup.html
---aw
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4f941e2d-a3af-4cde-97f4-fc9233ac52d2n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAChs6_kKta69QSM5bgMoedFWwFQhKV0e4G0u7aSs2RLF1Hie%2BA%40mail.gmail.com.
Just to say a big Thank You! to you all for being utterly patient and polite and positive
Alpha:
enter "e^1.1", press "more digits"
3.0041660239464331120584079535886723932826810260162727621297528605...
Sage:
RealLazyField()((e^1.1)).numerical_approx(200)
3.0041660239464333947978502692421898245811462402343750000000