Am 04.09.2014 um 08:24 schrieb Sergey B Kirpichev:
On Thu, Sep 04, 2014 at 07:54:32AM +0200, Joachim Durchholz wrote:
- Guard against regression. (Normal tests.)
If the SymPy fails
on the same, already reported code sample again (no matter for
which reason) - is that a regression?
Depends on
On Thu, Sep 04, 2014 at 07:54:32AM +0200, Joachim Durchholz wrote:
> - Guard against regression. (Normal tests.)
If the SymPy fails
on the same, already reported code sample again (no matter for
which reason) - is that a regression?
--
You received this message because you are subscribed to the
I think unit tests serve these purposes:
- Document an API by example. (We do that in doctests.)
- Guard against regression. (Normal tests.)
- Test emergent properties, i.e. those that cannot be trivially deduced
from reading the source code. (Doctest or normal test, depending on
whether the
It would be interesting to see how the positive definite is known.
Page https://en.wikipedia.org/wiki/Positive-definite_matrix gives an
example for which v.T*M*v gives 2*a**2 - 2*a*b + 2*b**2 - 2*b*c + 2*c**2
which is factored into a sum of squares (and hence nonnegative). I don't
know if we ha
On Wednesday, September 3, 2014 2:07:45 PM UTC-5, Sergey Kirpichev wrote:
>
> On Wednesday, September 3, 2014 6:44:06 AM UTC+4, Aaron Meurer wrote:
>>
>> I think such situations are OK, as long as you understand why the test
>> failed before and verified that the new test really tests the same
It should work now in the most recent build. Thanks for reporting the issue.
--
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 post
Am 03.09.2014 um 21:07 schrieb Sergey Kirpichev:
On Wednesday, September 3, 2014 6:44:06 AM UTC+4, Aaron Meurer wrote:
I think such situations are OK, as long as you understand why the test
failed before and verified that the new test really tests the same
thing.
1. We can make mistakes here
On Monday, 1 September 2014 22:37:31 UTC+2, James Crist wrote:
>
> /.../ Handling compiler options should definitely be added to the
> codewrappers though, but should be a separate issue.
>
Yes, I even went so far to write my own package to handle compilaton
(github.com/bjodah/pycompilation). Lo
On Wed, Sep 3, 2014 at 1:21 PM, James Crist wrote:
> Can you point me to some examples from your experience when
>> -ffast-math may result in loss of precision? I use it all the time in
>> all my production codes. So I would like to learn more about the
>> pitfalls.
>
>
> Personally, I've never ha
>
> I agree that it's a good idea. I guess a single header which is included
> is easiest to start with?
> Should the functions be implemented in C? or C and Fortran? Or C++ even?
> Are there any other functions except pow that needs special implementation?
>
As we're generating C compatible cod
On Wednesday, September 3, 2014 6:44:06 AM UTC+4, Aaron Meurer wrote:
>
> I think such situations are OK, as long as you understand why the test
> failed before and verified that the new test really tests the same
> thing.
>
1. We can make mistakes here.
2. Probably, we want to be sure, that we
Hi James,
On Mon, Sep 1, 2014 at 2:37 PM, James Crist wrote:
>>
>> I prefer either to pass -ffast-math flag (setting compiler flags is already
>> an issue since we need
>> to indicate optimization level, right?) or write a specialized callback to
>> be inlined (tuned to an Intel i7):
>
>
> I'm
> That being said, we do that in Theano. Putting a limit on the exponent
> that you do that would allow to don't loose too much precission for big
> exponent.
>
Yes, that sounds like a good idea. Did you make any investigation on what
is a suitable limit?
> I do like the specialized func
I fear that SymPy's matching of multiplicative inverses may be a problem in
RUBI, as the matcher may match too much.
By the way, assumptions should get to work on the patterns, currently they
seem not to work:
In [2]: x = symbols('x', real=False)
In [3]: w = Wild('w', real=True)
In [4]: x.mat
I think it's a corner case in terms of how the result is given precision.
It's off by 1 in this case. And being off by one doesn't affect the boolean:
```
>>> Float('.1',0)==.1
True
>>> Float('.1',1)==.1
True
```
On Tuesday, September 2, 2014 8:03:18 PM UTC-5, Aaron Meurer wrote:
>
> I think it'
Oh! It is my fault!
So I suggest to insert an error message doing A.cholesky() when A is not
positive definite, like in numpy :)
However, thank you very much Ondrej.
Good job!
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this gr
On Saturday, August 30, 2014 1:21:36 PM UTC+2, Sergey Kirpichev wrote:
>
>
> I don't think there's a big issue with this, because already
>> `ask(Q.real(x))` and `x.is_real` are different. My proposal is to have the
>> first call the second but not the other way around.
>>
>
> That's impossible
17 matches
Mail list logo
