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
On Mon, Apr 17, 2023 at 9:13 AM Ralf Hemmecke wrote:
>
> Hello,
>
> is there any particular reason why the term 12/5*q is not subtracted
> away by the first basis element?
The answer is that M_2(Gamma0(11)) is represented internally as the
direct sum of the cuspidal and eisenstein subspaces. In
There is also M.echelon_basis() which does that. I don't know why we need
two, does anyone?
John
On Mon, 17 Apr 2023 at 17:13, Ralf Hemmecke wrote:
> Hello,
>
> is there any particular reason why the term 12/5*q is not subtracted
> away by the first basis element?
>
> Ralf
>
>
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
Hello,
is there any particular reason why the term 12/5*q is not subtracted
away by the first basis element?
Ralf
┌┐
│ SageMath version 9.6, Release Date: 2022-05-15 │
│ Using Python 3.10.6. Type "help()"
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
23 matches
Mail list logo
