On Saturday, November 1, 2014 5:02:30 AM UTC-7, Sergey Kirpichev wrote:
>
> On Fri, Oct 31, 2014 at 11:45:19AM -0700, Richard Fateman wrote: 
> >    For closed-source commercial programs it is possible to report a bug 
> and 
> >    have an expert resolve the problem accurately and promptly. 
>
> Why this is impossible for open-source programs? 
>



 

It is not impossible,  but I am unaware of (unpaid) maintainers of 
open-source
programmers carrying pagers on their belts so they can be on call 24 hours
a day for resolving problems.  I am aware of commercial software vendors
who have such (paid) relationships with customers.   Of course it is 
possible
to pay people to help with open source code (e.g. some unix supporters).
But once you are paying, and not looking at the code yourself, it kind
of changes the equation.

>
> >    How likely is this??  I think it depends on 
> >    (a) how important the bug is 
> >    (b) how important the person reporting the bug is 
> >    (c) how much money/lives/etc depend on the bug being fixed. 
>
> Apparently, Spain universities doesn't matter for the 
> Wolfram Research. 

That sounds reasonable to me. 

>  Or they count "a serious mistake on the 
> determinant operation" as not important. 
>
Determinants where the entries are exact integers of extremely many digits
may not be terribly important.  What do you think? 

>
> Worst news - there is an inevitable vendor lock-in.  You can't give 
> your money someone else (but only single "group of experts", mostly 
> anonymous for you) to fix the issue. 
>
You can form a union of concerned users,  e.g. IBM had SHARE. 

>
> >    As for bugs,  consider the expression (in mathematica syntax) 
> >    Sum[x^i, {i, 0, n}] 
> >    which is computed in closed form, but consider specific values, 
> >    say 
> >    x=2, n=-4. 
> >    for which the correct answer is -7/8  even though Sum[2^i,{i.0,-4}] 
> comes 
> >    out 0. 
> >    Now try it in other programs. 
>
> Well, SymPy doesn't have this inconsistency: 
>

That;s good.  Mathematica, Maple, and Maxima (unless you set a flag) all 
shared
the same defect.  There are others that are presumably shared with sympy.
I have never used sympy.  Judging from the few lines below, it looks
kind of clumsy with respect to declarations.
 

> In [3]: k, n = symbols('k, n', integer=True) 
>
> In [4]: f = symbols('f', cls=Function) 
>
> In [5]: summation(2**k, (k, 0, -4)) 
> Out[5]: -7/8 
>
> In [6]: summation(2**k, (k, 0, n)) 
> Out[6]: 
>  n + 1     
>  2      - 1 
>
>  In [7]: _.subs(n, -4) 
>  Out[7]: -7/8 
>
> The issue here is that Mathematica count n as positive: 
>
> In[9]:= Sum[f[i], {i, 0, -2}] 
> Out[9]= 0 
>
> While SymPy uses the Karr convention instead: 
>
Michael Karr?  Who named it the Karr convention?   K.F. Gauss?
 

>
> In [10]: summation(f(k), (k, 0, -4)) 
> Out[10]: -f(-3) - f(-2) - f(-1) 
>
> (I don't remember, probably this will be invalid too for infinite n.  So, 
> maybe we have a very similar issue for n=-oo due to implicit assumption 
> that n is a 
> finite number.) 
>

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/3085b893-63c7-472a-a1b1-8a12cf12fd26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to