Re: [sage-devel] Default precision for floats

2015-09-20 Thread Thierry Dumont
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

Re: [sage-devel] Default precision for floats

2015-09-20 Thread William Stein
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

Re: [sage-devel] Default precision for floats

2015-09-20 Thread Vincent Delecroix
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

Re: [sage-devel] Default precision for floats

2015-09-20 Thread Thierry Dumont
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:

Re: [sage-devel] Default precision for floats

2015-09-20 Thread Volker Braun
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

Re: [sage-devel] Default precision for floats

2015-09-20 Thread Thierry Dumont
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

Re: [sage-devel] Default precision for floats

2015-09-20 Thread Volker Braun
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)

Re: [sage-devel] Default precision for floats

2015-09-20 Thread William Stein
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) >>

Re: [sage-devel] Default precision for floats

2015-09-20 Thread Volker Braun
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' |

Re: [sage-devel] Default precision for floats

2015-09-20 Thread Thierry Dumont
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

Re: [sage-devel] Default precision for floats

2015-09-20 Thread rjf
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,

Re: [sage-devel] Default precision for floats

2015-09-20 Thread William Stein
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