Re: [sympy] Maintaining accuracy in Float Operations

2020-09-18 Thread Oscar Benjamin
Hi Roshan,

Thanks for looking at this. Just as a note to anyone interested in
this there has already been some discussion on the issue tracker:

https://github.com/sympy/sympy/issues/20071

Oscar

On Fri, 18 Sep 2020 at 13:00, Roshan VS  wrote:
>
> Before I begin I would like to introduce myself, I'm Roshan (my username's 
> weakit everywhere), and programming is a hobby of mine. I might not be as 
> experienced as the average sympy programmer, and I'm still learning the 
> ropes, so please be patient with me.
>
> The idea of a CAS is something I find very interesting, and that's why I 
> would like to learn how a CAS would work, and along with that, I think I can 
> gain a lot of experience helping out with sympy.
>
> Anyways, coming to my issue:
>
> Currently, when two numbers of different precision are used in an arithmetic 
> operation, the result is returned with the higher precision of the two Floats:
>
> >>> Float(0.1, 3) * Float(3.1415, 5)
> 0.31417
>
> I'm looking to change this behaviour so that the result is in the lower of 
> the two precisions, to have a more accurate result.
>
> I did notice this in the documentation:
>
> The precision of a number determines 1) the precision to use when performing 
> arithmetic with the number, and 2) the number of digits to display when 
> printing the number. When two numbers with different precision are used 
> together in an arithmetic operation, the higher of the precisions is used for 
> the result."
>
> So the displayed precision should not be used as a model of error propagation 
> or significance arithmetic; rather, this scheme is employed to ensure 
> stability of numerical algorithms.
>
> over here: 
> https://docs.sympy.org/latest/modules/evalf.html#floating-point-numbers
>
> "this scheme is employed to ensure stability of numerical algorithms" is what 
> I'm focusing on. Would the change I proposed break anything, or cause any 
> un-stability?
>
> It's a rather simple fix, and all tests other than a few expected document 
> and example tests pass.
>
> Is there something I'm missing, and also anything against this proposal? This 
> is how I think Floats should behave, but I would also like to hear about any 
> problems that this might create.
>
> Thanks for your time.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/ed969819-f734-4665-aa38-8871dd01338dn%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxQ-HmAvrMTf9aXOYg2U1u5mGb4ZghnenjVRhcKMpO%3DhiA%40mail.gmail.com.


[sympy] Maintaining accuracy in Float Operations

2020-09-18 Thread Roshan VS
Before I begin I would like to introduce myself, I'm Roshan (my username's 
weakit everywhere), and programming is a hobby of mine. I might not be as 
experienced as the average sympy programmer, and I'm still learning the 
ropes, so please be patient with me. 

The idea of a CAS is something I find very interesting, and that's why I 
would like to learn how a CAS would work, and along with that, I think I 
can gain a lot of experience helping out with sympy.

Anyways, coming to my issue:

Currently, when two numbers of different precision are used in an 
arithmetic operation, the result is returned with the higher precision of 
the two Floats:

>>> Float(0.1, 3) * Float(3.1415, 5)
0.31417 

I'm looking to change this behaviour so that the result is in the lower of 
the two precisions, to have a more accurate result.

I did notice this in the documentation:

The precision of a number determines 1) the precision to use when 
performing arithmetic with the number, and 2) the number of digits to 
display when printing the number. When two numbers with different precision 
are used together in an arithmetic operation, the higher of the precisions 
is used for the result."

So the displayed precision should not be used as a model of error 
propagation or significance arithmetic; rather, this scheme is employed to 
ensure stability of numerical algorithms.

over here: 
https://docs.sympy.org/latest/modules/evalf.html#floating-point-numbers 


"this scheme is employed to ensure stability of numerical algorithms" is 
what I'm focusing on. Would the change I proposed break anything, or cause 
any un-stability? 

It's a rather simple fix, and all tests other than a few expected document 
and example tests pass.

Is there something I'm missing, and also anything against this proposal? 
This is how I think Floats should behave, but I would also like to hear 
about any problems that this might create.

Thanks for your time.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/ed969819-f734-4665-aa38-8871dd01338dn%40googlegroups.com.


[sympy] Introduction

2020-09-18 Thread 138_Deepak Singh
Hi everyone , my name is Deepak singh  currently pursuing Electronics and 
communication engineering from UIET Panjab University .i am 3rd year 
student and want to contribute in this organization for GSOC2021

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/080d0014-1f37-49b3-b064-fefda6f9342cn%40googlegroups.com.