when passing python ints to realfield, they don't get cast to sage integers
this can cause wrong answers
example:
RR=RealField(100)
set_random_seed(3)
n1=randint(1000,)#n1=8059
n2=randint(1000,)#n2=9042
print(n1,'/',n2,'=',sep='')
print(RR(n1/n2))#passing as 8059,
sage version: 9.4
operating system: fedora 35
float literals passed to realfield can yield wrong answers
example:
RR=RealField(200)
print(RR(1.1))
print(RR(11/10))
print()
print(RR(2*1.1))
print(RR(2*11/10))
output:
1.10
1.10
#x27;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 h
ust the pre-processing of Sage args to
represent float literals like 1.1 as rationals like 11/10, unless
overridden by the user.
I have a lot more to say on this topic, but for now I'll end there.
-aw
On Saturday, April 15, 2023 at 5:57:20 PM UTC-6 William Stein wrote:
> On Sat, Apr 15
/input?i=100+digits+of+e%5E%2811%2F10%29
Yeah, good catch, so even Wolfram screws up sometimes!
But that doesn't give you Sage devs a free pass to screw up as much as you
want.
You and Wolfram should both be trying to eliminate all such mistakes, right?
-aw
--
You received this message be
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 shorthan
. Hence the result is
not 2.2, but some other value, a value with junk in it.
Users should never be handed junk.
And defaults should always be what most users expect (especially when it's
99%+ of users, as it is in the case).
-aw
--
You received this message because you are subscribed t
the other "permabugs" you know of that involve float literals?
-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+unsubscr...@googlegroup
user would look at the
output of RealField(200)(2*1.1) and say, "Yeah, that's awesome, that's
exactly what I was looking for! Thanks, Sage!"
Describe the kind of user who would say that.
And then ask yourself, what percentage of Sage users are like that?
How about this: wh
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
coefficients
Very cool fact, thanks!
-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+unsubscr...@googlegroups.com.
To view this discussion
ly meet the
behavior requirements for a very high precision environment?
If that one tiny change would make it a good environment, whose answers are
always the exact answers truncated to the requested precision, then why the
heck would you not make that change?
It would give you something mor
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
1298
RealLazyField()((e^(11/10))).numerical_approx(400)
3.00416602394643311205840795358867239328268102601627276212975286052863219354994639393702584656011004248292917244402984647
-aw
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and sto
tter.
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
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
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"
er "e^1.1", press "more digits"
3.0041660239464331120584079535886723932826810260162727621297528605...
Sage:
RealLazyField()((e^1.1)).numerical_approx(200)
3.004166023946433394797850269242189824581146240234375000
Why is interpreting the 1.1 as 11/10 easy for Alpha, but hard for you guys?
-aw
--
Yo
mance implications, integration implications,
etc.
I don't want you guys to have to do a lot of work. I'm suggesting a simple
pre-processing solution that would take almost no work, and would have zero
performance implications or integration implications.
-aw
--
You received this message
ision
in anything that they do.
Only a math person, doing math, has a use for 1000 bits.
So RealField and RealLazyField should use the math semantics.
They should see 1.1 as 11/10.
-aw
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group
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
Thanks for this, but that would be a global substitution, right?
I'm arguing just for a local substitution, in the high-precision
environments only.
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, h
22 matches
Mail list logo
