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 3:47 AM aw wrote:
>
> On Saturday, April 15, 2023 at 9:12:09 PM UTC-6 Nils Bruin wrote:
>
> 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
23 matches
Mail list logo
