Alpha:
enter "e^1.1", press "more digits"
3.0041660239464331120584079535886723932826810260162727621297528605...
Sage:
RealLazyField()((e^1.1)).numerical_approx(200)
3.004166023946433394797850269242189824581146240234375000
Sage is not Wolfram Alpha, and neither is Mathematica. Alpha is
Just to say a big *Thank You!* to you all for being utterly patient and
polite and positive
+100
--
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
Dear SageMath developers,
Just to say a big *Thank You!* to you all for being utterly patient and
polite and positive, even when we do not deserve it (I speak for myself).
Best,
Guillermo
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On Tue, Apr 18, 2023 at 7:35 PM aw wrote:
> [...] You and your people have a *very strong* tendency to nitpick details
> instead of staying focused on the big picture.
You're right, respecting details is indeed a very strong
characteristic of professional mathematicians.
--
William
On Tuesday, April 18, 2023 at 6:27:50 PM UTC-6 William Stein wrote:
On Tue, Apr 18, 2023 at 5:15 PM aw wrote:
> In high-precision environments like RealField(1000), Sage should
*definitely* use the math semantics, because physics people, or engineers,
or any other applied type folks, have
You keep saying
> Any normal mathematician who writes "e^1.1" intends that to mean
"e^(11/10)".
To be honest, I don't think that is the case, if a paper presented to you
some constant gamma = 1.1, you would not assume that gamma is 11/10, but
instead that an approximation to 2 decimal digits for
On Tue, Apr 18, 2023 at 5:15 PM aw wrote:
> In high-precision environments like RealField(1000), Sage should *definitely*
> use the math semantics, because physics people, or engineers, or any other
> applied type folks, have zero use for 1000 bits of precision in anything that
> they do.
On Tue, Apr 18, 2023 at 8:15 PM aw wrote:
> On Tuesday, April 18, 2023 at 4:19:45 PM UTC-6 Nils Bruin wrote:
>
>
> 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):
>
On Tuesday, April 18, 2023 at 4:19:45 PM UTC-6 Nils Bruin wrote:
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
On Tuesday, April 18, 2023 at 4:19:45 PM UTC-6 Nils Bruin wrote:
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.
This is true in some context, but not others.
In
On Tue, Apr 18, 2023 at 8:06 PM aw wrote:
> On Tuesday, April 18, 2023 at 4:14:41 PM UTC-6 David Roe wrote:
>
> Did you read my message from last night? I highlighted exactly the
> problems with what you're suggesting.
> David
>
>
> In that post you outlined some pretty heavy ways of doing it.
On Tuesday, April 18, 2023 at 4:14:41 PM UTC-6 David Roe wrote:
Did you read my message from last night? I highlighted exactly the
problems with what you're suggesting.
David
In that post you outlined some pretty heavy ways of doing it. Those would
be a lot of work, with performance
On Tuesday, April 18, 2023 at 4:23:10 PM UTC-6 Dima Pasechnik wrote:
1) compute t=e^1.1
2) 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[...]).
If Python is
On Tue, 18 Apr 2023, 22:59 aw, wrote:
> 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
On Tuesday, 18 April 2023 at 14:59:30 UTC-7 aw wrote:
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
On Tuesday, April 18, 2023 at 3:20:04 PM UTC-6 aw wrote:
RealLazyField(e^1.1).numerical_approx(200)
Whoops, typo. Should be:
RealLazyField()(e^1.1).numerical_approx(200)
Sorry.
-aw
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On Tuesday, April 18, 2023 at 3:59:30 PM UTC-6 aw wrote:
... the user-supplied string "RealLazyField(200)(e^1.1)"...
Whoops, typo: initially I had RealField there, and that syntax is right.
Then I changed RealField to RealLazyField, to emphasize that the problem
applies equally to it.
But I
Did you read my message from last night? I highlighted exactly the
problems with what you're suggesting.
David
On Tue, Apr 18, 2023 at 5:59 PM aw wrote:
> 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
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"
On Tue, 18 Apr 2023, 22:20 aw, wrote:
> 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)
>
>
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)
On Tuesday, 18 April 2023 at 11:33:38 UTC-7 aw wrote:
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
On Tue, 18 Apr 2023, 19:33 aw, wrote:
>
>
> 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
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
On Mon, Apr 17, 2023 at 10:12 PM aw wrote:
>
> To the folks defending RealField's behavior: the reasons you cite for why
> it's acceptable would also apply to low-precision environments like single or
> double precision.
>
> But very high precision environments have a different purpose than
On Mon, Apr 17, 2023 at 9:11 PM Nils Bruin wrote:
>
> 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
On Monday, 17 April 2023 at 20:44:36 UTC-7 David Roe wrote:
So I think a concrete version of Dima's suggestion would be
1. 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
On Mon, Apr 17, 2023 at 7:39 PM aw wrote:
> On Monday, April 17, 2023 at 4:05:56 PM UTC-6 Nils Bruin wrote:
>
> 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
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.
On Monday, April 17, 2023 at 4:05:56 PM UTC-6 Nils Bruin wrote:
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
On Monday, April 17, 2023 at 4:05:56 PM UTC-6 Nils Bruin wrote:
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 - 1
This shows that cos(pi200/13) is remarkably close to satisfying a sextic
equation with remarkably small
On Monday, 17 April 2023 at 14:58:49 UTC-7 aw wrote:
fixing a typo: it should be "exact irrationals like sqrt(2)"
Ah, NOW I see what the problem likely is: I think you're misled by the
field being called "RealField". So ... yeah ... it's not. It should
probably be called RealFloats or
On Monday, 17 April 2023 at 14:12:43 UTC-7 aw wrote:
(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.
But you
fixing a typo: it should be "exact irrationals like sqrt(2)"
--
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
To the folks defending RealField's behavior: the reasons you cite for why
it's acceptable would also apply to low-precision environments like single
or double precision.
But very high precision environments have a different purpose than those
low-precision environments. So you shouldn't be
I am beginning to think that more ball/interval arithmetic should be
involved here, in particular as dealing with RealField is not much faster
than RealBallField with the same precision, yet allows a degree of control
over the error propagation.
(and perhaps the default 53 bits out to be bumped
On Monday, 17 April 2023 at 05:04:00 UTC-7 Emmanuel Briand wrote:
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?
No, because RR(11/10) is not a literal. In principle 11/10 could be a
"rational
This has been an interesting discussion, because it brings up again the
inherent tradeoffs present in writing general-purpose software. We (not
just Sage, but other similar systems) want something that is usable by
those who need floating-point to do what it must do, as well as be
On Monday, 17 April 2023 at 04:13:51 UTC-7 John Cremona wrote:
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.100088817841970012523233890533447265625000
sage:
Interesting. The two inputs have different types
type(RR(11/10))
type(RR(1.1))
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
On Mon, Apr 17, 2023 at 12:20 PM Michael Orlitzky wrote:
>
> On Sun, 2023-04-16 at 19:46 -0700, aw wrote:
> >
> > Unbelievable.
> > This is failing a basic consistency check: if x==y, then we should have
> > f(x)==f(y) for any function f.
> >
> > The problem here is that float literals are being
On Sun, 2023-04-16 at 19:46 -0700, aw wrote:
>
> Unbelievable.
> This is failing a basic consistency check: if x==y, then we should have
> f(x)==f(y) for any function f.
>
> The problem here is that float literals are being mishandled. The string
> "0.5" should be interpreted as 1/2, unless
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.100088817841970012523233890533447265625000
sage: RealField(200)(RR(1.1))
On Sun, 2023-04-16 at 12:47 +0100, Dima Pasechnik wrote:
>
> perhaps the preparser should have an option to convert the floating
> point input into rationals.
We should try ZZ first, but yeah, something like that. If Sage thinks
QQ(x) == float(x), then the former should be preferred. Or maybe it
On Sun, 2023-04-16 at 10:50 -0700, Nils Bruin wrote:
>
> That's a facetious example that sticks to values that can be exactly
> represented in binary floats. These identities don't hold generally:
>
> sage: 49*(1.0/49) == ZZ(1)
> False
>
> (it depends on your working precision if rounding
On Saturday, April 15, 2023 at 5:25:27 PM UTC-6 Michael Orlitzky wrote:
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()
On Sunday, April 16, 2023 at 4:44:56 PM UTC-6 Nils Bruin wrote:
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
On Sunday, April 16, 2023 at 4:56:05 PM UTC-6 Edgar Costa wrote:
Wolfram Alpha also has beginners and students as a big chunk of its user
base, and they get the default semantics exactly right.
Do they?
https://www.wolframalpha.com/input?i=100+digits+of+e%5E1.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
>
I
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.1 (infinitely many
zeros)
That's the
Awesome, let's talk about floating point semantics.
There are two main kinds, that I can see.
One is "ordinary person" semantics, the other is IEEE-like semantics.
Ordinary-person semantics is what you learned in grade school.
In grade school, suppose we want to add 1.1 to 2.8324, using pencil
On Sunday, 16 April 2023 at 04:40:50 UTC-7 Michael Orlitzky wrote:
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
On Sun, 16 Apr 2023 at 15:52, Trevor Karn wrote:
>
> 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
On Sun, 16 Apr 2023, 15:52 Trevor Karn, wrote:
> 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
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
On Sun, Apr 16, 2023 at 12:25 AM Michael Orlitzky wrote:
>
> On Sat, 2023-04-15 at 18:20 -0400, David Roe wrote:
> > I agree with William that you should refrain from insulting the Sage
> > developers, especially when the underlying problem comes from your
> > misunderstanding of how floating
On Sun, Apr 16, 2023 at 12:40 PM Michael Orlitzky wrote:
>
> On Sat, 2023-04-15 at 19:11 -0700, Nils Bruin wrote:
> >
> > I fail to see what the reasonable expectations are here. As soon as you
> > multiply by "0.5" you now have an "imprecise" result. When people learn to
> > use a scientific
On Sat, 2023-04-15 at 19:11 -0700, Nils Bruin wrote:
>
> I fail to see what the reasonable expectations are here. As soon as you
> multiply by "0.5" you now have an "imprecise" result. When people learn to
> use a scientific calculator properly they are very quickly confronted with
> the
On Sun, Apr 16, 2023 at 2:25 AM Michael Orlitzky wrote:
>
> 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
>
Doesn't this complicates citing
On Saturday, 15 April 2023 at 16:25:27 UTC-7 Michael Orlitzky wrote:
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
On Sat, 2023-04-15 at 16:56 -0700, William Stein wrote:
>
> I agree with you that it's best to assume that the original poster "aw" does
> understand the semantics of floating point numbers in Sage, and just doesn't
> like them. I think you also understand the semantics of floating point in
>
On Sat, 15 Apr 2023 at 22:39, aw wrote:
>
>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.
That
On Sat, Apr 15, 2023 at 4:25 PM Michael Orlitzky wrote:
>
> On Sat, 2023-04-15 at 18:20 -0400, David Roe wrote:
> > I agree with William that you should refrain from insulting the Sage
> > developers, especially when the underlying problem comes from your
> > misunderstanding of how floating
On Sat, 2023-04-15 at 18:20 -0400, David Roe wrote:
> I agree with William that you should refrain from insulting the Sage
> developers, especially when the underlying problem comes from your
> misunderstanding of how floating point arithmetic works.
I was given this response many times, and I
I agree with William that you should refrain from insulting the Sage
developers, especially when the underlying problem comes from your
misunderstanding of how floating point arithmetic works.
To respond to the content of your message, finite precision real fields in
Sage are implemented using
https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md
On Sat, Apr 15, 2023 at 2:39 PM aw wrote:
>
> 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
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
67 matches
Mail list logo
