On Monday, September 21, 2015, rjf wrote:
>
>
>>
>>
>> >
>> >(Richard) While it is tempting to add every possible tool to Sage,
>> thinking out of the
>> > box can be productive.
>> >
>> > (one answer: there is a bootstrapping problem if you have to have a
>> working
>> > Sage in order to build
>
>
>
> >
> >(Richard) While it is tempting to add every possible tool to Sage,
> thinking out of the
> > box can be productive.
> >
> > (one answer: there is a bootstrapping problem if you have to have a
> working
> > Sage in order to build a working Sage.)
>
> (William)One answer to w
Le 20/09/2015 20:28, rjf a écrit :
If the original program has constants that are good for ordinary
floating precision,
then increasing the precision without increasing the accuracy may not do
what
you want.
For example, converting 3.1415926 (etc) by extending with decimal or
binary 0's might
On Sun, Sep 20, 2015 at 11:28 AM, rjf wrote:
> If the original program has constants that are good for ordinary floating
> precision,
> then increasing the precision without increasing the accuracy may not do
> what
> you want.
> For example, converting 3.1415926 (etc) by extending with decimal o
If the original program has constants that are good for ordinary floating
precision,
then increasing the precision without increasing the accuracy may not do
what
you want.
For example, converting 3.1415926 (etc) by extending with decimal or
binary 0's might
not do the right thing.
In fact, co
Yes, a more complete regex can be found easily with google or by using the
one from src/sage/repl/preparse.py
On Sunday, September 20, 2015 at 6:11:25 PM UTC+2, vdelecroix wrote:
> Would not work with 'x=.8' (can be fixed with replacing the first \+
with a \*) nor 'x=2e3' (this is more annoyin
On 20/09/15 12:59, Volker Braun wrote:
On Sunday, September 20, 2015 at 5:02:12 PM UTC+2, tdumont wrote:
Without changing the default precision, and using your solution, we
revert to something where we must "declare" the float values:
x=field(137.8)
in place of
x=137.8
There is an app for th
On Sunday, September 20, 2015 at 5:02:12 PM UTC+2, tdumont wrote:
>
> Without changing the default precision, and using your solution, we
> revert to something where we must "declare" the float values:
> x=field(137.8)
> in place of
> x=137.8
>
There is an app for that!
$ echo 'x=137.8' | se
Le 20/09/2015 17:11, William Stein a écrit :
On Sun, Sep 20, 2015 at 8:02 AM, Thierry Dumont
wrote:
Le 20/09/2015 16:26, Volker Braun a écrit :
Why change the default? Global state is always a liability; Just don't
do it. Make the field a parameter to your code:
def frobnicate(x,y, field=Non
On Sun, Sep 20, 2015 at 8:02 AM, Thierry Dumont
wrote:
> Le 20/09/2015 16:26, Volker Braun a écrit :
>>
>> Why change the default? Global state is always a liability; Just don't
>> do it. Make the field a parameter to your code:
>>
>> def frobnicate(x,y, field=None)
>> if field is None:
>>
Le 20/09/2015 16:26, Volker Braun a écrit :
Why change the default? Global state is always a liability; Just don't
do it. Make the field a parameter to your code:
def frobnicate(x,y, field=None)
if field is None:
from sage.structure.element import get_coercion_model
field
On Sunday, September 20, 2015, Volker Braun wrote:
> Why change the default? Global state is always a liability; Just don't do
> it.
>
+1. I was about to post the same.Explicit is better than implicit.
> Make the field a parameter to your code:
>
> def frobnicate(x,y, field=None)
> if
Why change the default? Global state is always a liability; Just don't do
it. Make the field a parameter to your code:
def frobnicate(x,y, field=None)
if field is None:
from sage.structure.element import get_coercion_model
field = get_coercion_model().common_parent(x, y)
Dear Colleagues,
I have managed to code this...
But I have a question before pushing the tickket.
What I can do nowadays:
sage: set_precision(100)
sage: x=1.
sage: x.parent()
Real Field with 100 bits of precision
sage: ComplexNumber(1.,2.).parent()
Complex Field with 99 bits of precision
sage:
Le 13/09/2015 01:36, Vincent Delecroix a écrit :
It would indeed be cool to have an option to change interactively the
precision...
preparser.set_precision?
or simply
set_precision?
Vincent
I can look at this and propose an implementation...
Thanks!
t.
On 12/09/15 19:49, David Roe wrote:
It would indeed be cool to have an option to change interactively the
precision...
preparser.set_precision?
or simply
set_precision?
Vincent
On 12/09/15 19:49, David Roe wrote:
One approach would be to change "RealNumber('%s')" % num on line 739
of sage.repl.preparse to "RealNumber('%s',min
One approach would be to change "RealNumber('%s')" % num on line 739
of sage.repl.preparse to "RealNumber('%s',min_prec=1000)" % num.
David
On Sat, Sep 12, 2015 at 12:24 PM, Thierry Dumont
wrote:
> I have a program with a lot of floating point constants/variables (this is a
> translation of a C++
I have a program with a lot of floating point constants/variables (this
is a translation of a C++ program).
Nowadays -by default- all these values live in RealField(53).
But, as my problem is a bit ill conditioned, I would like to compute in
higher precision, say in RealField(1000).
Is there
18 matches
Mail list logo
