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
not do the right thing.
In fact, converting 0.1, which is a binary float not equal to 1/10
exactly, might change
the situation enough so that
f(a,b,c)  in single-float
f(a,b,c)  in 100 bits



I know that... but, my constants are defined by values of elementary 
functions.

The solution proposed by William is perfect for me, and very consistent:

sage: atan(1.0)
0.785398163397448
sage: RealNumber=RealField(300)
sage: atan(1.0)
0.785398163397448309615660845819875721049292349843776455243736148076954101571552249657008706
age: RealNumber=RealField()
sage: atan(1.0)
0.785398163397448
sage: ComplexNumber=ComplexField(200)
sage: x=ComplexNumber(1,1)
sage: cos(x)
0.83373002513114904888388539433509447980987478520962931227072 - 
0.98889770576286509638212954089268618864214969503314760753682*I


great...


differ not because the second is more accurate, but because something rather
different is being computed.   e.g. if a= 0.1.

Also, if someone is automatically translating C to python, then
automatically
inserting  MyChosenPrecisionReal('   ')   around every float should be easy.

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.)


On Sunday, September 20, 2015 at 9:20:35 AM UTC-7, Volker Braun wrote:

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 annoying).

--
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 post to this group, send email to sage-devel@googlegroups.com
.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
<>

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 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)
> x, y = field(x), field(y)
> ...
>
> frobnicate(1, 2, field=RealField(100))
>
> --
> 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 post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my massive iPhone 6 plus.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


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 that!

$ echo 'x=137.8' | sed 's/\([0-9]\+\.[0-9]\+\)/field(\1)/g'
x=field(137.8)


Would not work with 'x=.8' (can be fixed with replacing the first \+ 
with a \*) nor 'x=2e3' (this is more annoying).


--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


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:

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)
  x, y = field(x), field(y)
  ...

frobnicate(1, 2, field=RealField(100))

--
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 post to this group, send email to sage-devel@googlegroups.com
.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.



Ok...
The origin of the discussion was: I have a code, translated from C, where a
I want to be able to increase the precision  of the float constants (there
are many of them -about 400!-), as the problem is ill conditioned David
Roe proposed to patch the parser.

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
My principal motivation was lazyness :-)
But ok, I understand your argument; and also, patching the parser is not
very smart programing...



Just type

 RealNumber = RealField(300)

and now every single real literal will be a 300-bit float.Your
problem is solved.  All the pre-parser does is replace real literals
with RealNumber('literal'), e.g.,



Aaaah, yes!
Nice,
Thanks!
yours
t.

sage: preparse('3.14')
"RealNumber('3.14')"

You can thus trivially re-interpret all real literals in Sage programs
(or worksheets) in absolutely any way you want by redefining
RealNumber.  This only impacts that one scope and session too, so it
won't mess up the library in any way (which a priori any change to the
pre-parser itself could).

Similar remarks apply for integer literals.

sage: preparse('389')
'Integer(389)'

I wish I was writing this remark in the README.md of a
pip-hosted package called sage-preparser, which is an also popular
IPython extension...

[1] 
https://cloud.sagemath.com/projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/files/support/2015-09-20-080623-real_precision.sagews

William



t.



--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.






--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
<>

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 annoying). 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


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 = get_coercion_model().common_parent(x, y)
 x, y = field(x), field(y)
 ...

frobnicate(1, 2, field=RealField(100))

--
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 post to this group, send email to sage-devel@googlegroups.com
.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Ok...
The origin of the discussion was: I have a code, translated from C, 
where a I want to be able to increase the precision  of the float 
constants (there are many of them -about 400!-), as the problem is ill 
conditioned David Roe proposed to patch the parser.


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
My principal motivation was lazyness :-)
But ok, I understand your argument; and also, patching the parser is not 
very smart programing...


t.


--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
<>

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)
x, y = field(x), field(y)
...

frobnicate(1, 2, field=RealField(100))

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


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)
>>  if field is None:
>>  from sage.structure.element import get_coercion_model
>>  field = get_coercion_model().common_parent(x, y)
>>  x, y = field(x), field(y)
>>  ...
>>
>> frobnicate(1, 2, field=RealField(100))
>>
>> --
>> 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 post to this group, send email to sage-devel@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> Ok...
> The origin of the discussion was: I have a code, translated from C, where a
> I want to be able to increase the precision  of the float constants (there
> are many of them -about 400!-), as the problem is ill conditioned David
> Roe proposed to patch the parser.
>
> 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
> My principal motivation was lazyness :-)
> But ok, I understand your argument; and also, patching the parser is not
> very smart programing...
>

Just type

RealNumber = RealField(300)

and now every single real literal will be a 300-bit float.Your
problem is solved.  All the pre-parser does is replace real literals
with RealNumber('literal'), e.g.,

   sage: preparse('3.14')
   "RealNumber('3.14')"

You can thus trivially re-interpret all real literals in Sage programs
(or worksheets) in absolutely any way you want by redefining
RealNumber.  This only impacts that one scope and session too, so it
won't mess up the library in any way (which a priori any change to the
pre-parser itself could).

Similar remarks apply for integer literals.

   sage: preparse('389')
   'Integer(389)'

I wish I was writing this remark in the README.md of a
pip-hosted package called sage-preparser, which is an also popular
IPython extension...

[1] 
https://cloud.sagemath.com/projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/files/support/2015-09-20-080623-real_precision.sagews

William


> t.
>
>
>
> --
> 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 post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
William (http://wstein.org)

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


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' | sed 's/\([0-9]\+\.[0-9]\+\)/field(\1)/g'
x=field(137.8)

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


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
sage: set_precision()
sage: x=1.
sage: x.parent()
Real Field with 53 bits of precision

sage: set_precision(100)
sage: x=RealNumber(1.)
sage: print x
1.000 #okay

but:

sage: set_precision(100)
sage: x=RealNumber(1)
sage: print x
1.00
sage: x.parent()
Real Field with 53 bits of precision

So, what do you think of that?
Is it necessary to modify (the parser) so that:
sage: set_precision(100)
sage: x=RealNumber(1)
returns something in "Real Field with 100 bits of precision"?
I recall that the idea was to change the default behavior of the parsed 
floats.

Doing this is possible but not with a very smart implementation.

t.



Le 13/09/2015 08:55, Thierry Dumont a écrit :

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:

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++ 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 a possibility to change the default behavior of say,

x=1.0
x.parent()
Real Field with 53 bits of precision

so that:

x=1.0
x.parent()

gives
Real Field with 1000 bits of precision
?

Yours
t.

--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.








--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
<>

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, converting 0.1, which is a binary float not equal to 1/10 exactly, 
might change
the situation enough so that 
f(a,b,c)  in single-float 
f(a,b,c)  in 100 bits

differ not because the second is more accurate, but because something rather
different is being computed.   e.g. if a= 0.1.

Also, if someone is automatically translating C to python, then 
automatically
inserting  MyChosenPrecisionReal('   ')   around every float should be easy.

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.)


On Sunday, September 20, 2015 at 9:20:35 AM UTC-7, Volker Braun wrote:
>
> 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 annoying). 
>>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


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 extending with decimal or
> binary 0's might
> not do the right thing.
> In fact, converting 0.1, which is a binary float not equal to 1/10 exactly,
> might change
> the situation enough so that
> f(a,b,c)  in single-float
> f(a,b,c)  in 100 bits
>
> differ not because the second is more accurate, but because something rather
> different is being computed.   e.g. if a= 0.1.
>
> Also, if someone is automatically translating C to python, then
> automatically
> inserting  MyChosenPrecisionReal('   ')   around every float should be easy.

The Sage preparser already inserts

   RealNumber('  ')

around every floating point literal.My suggestion, which solves
the problem is to redefine RealNumber to be RealField(300) (say).

By the way, the builtin RealNumber function does take into account the
actual number of digits given in the input -- it doesn't just default
to 53 bits.

Richard does have a point about interpretation though -- you may want
to output and input using base 16 instead of base 10.

>
> 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.)

One answer to what?  Huh?

>
>
> On Sunday, September 20, 2015 at 9:20:35 AM UTC-7, Volker Braun wrote:
>>
>> 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 annoying).
>
> --
> 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 post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
William (http://wstein.org)

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.