Re: [sage-devel] Unify error for trying to invert non-invertible elements

[Dave Morris]

-1 from me.

Looking at just a few uncovered some that I think are definitely not 
ArithmeticError.

Examples:
There is an occurrence of ValueError('{} is not invertible') in the 
lift_isometry method of cliffordalgebra.py.  Lifting an isometry is clearly not 
an arithmetic operation.  ValueError is correct here.
There is an occurrence of TypeError('the A-basis is defined only when 2 
is invertible') in the method to find an `A`-basis of an Iwahori-Hecke algebra. 
 Finding such a basis is clearly not an arithmetic operation.  Perhaps this 
should be a ValueError instead of a TypeError, though.
RuntimeError("morphism is not invertible").  I think that finding the 
inverse of a morphism between two objects of a category is clearly not an 
arithmetic operation.  Perhaps this should be a ValueError rather than a 
RuntimeError.

If you want to unify, I think ValueError might work.  But I think they all need 
to be inspected, not just assume a single error type fits.

> On Feb 5, 2024, at 4:44 AM, 'Martin R' via sage-devel 
>  wrote:
> 
> Dear all,
> 
> currently, when trying to invert a non-invertible element, one of the 
> following errors is raised (found using `grep -r --include=*.{py,pyx} --color 
> -nH --null -e "Error(.*invertible" *`):
> • 21 ValueError('{} is not invertible')
> • 11 ZeroDivisionError("element is not invertible")
> • 10 TypeError('the A-basis is defined only when 2 is invertible')
> • 8 ArithmeticError("self must be invertible to have a multiplicative 
> order")
> • 2 RuntimeError("morphism is not invertible")
> • 2 NotImplementedError("matrix must be invertible")
> 
> Travis and I would like to propose to unify these to "ArithmeticError".  If 
> nobody objects, I would prepare a PR within the next few days.
> 
> Best wishes,
> 
> Martin
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/d0637584-4908-4101-8e1b-74ec0477ff84n%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4A0E1F77-27A7-4DF3-BB18-636853BF4CC0%40deductivepress.ca.

Re: [sage-devel] Definite Integral wrong

[Dave Morris]

I agree with the general analysis, but I think the statement "Any answer 
that supplies only one answer is wrong." goes too far.  It may be the case 
that sage works inherently in the complex domain, and is unable to 
understand that elementary calculus and certain other fields want to remain 
in the real domain, but it would not be "wrong" to have a program that 
operates differently.  It is not "wrong" to work in the real domain and 
understand that "\sqrt{2}" means 1.414... (the "principal square root"), 
not -1.414...  Indeed, I think sage would need to be able to do to be 
really useful for most 1st semester calculus students.  In this situation, 
there is a unique correct answer, so returning two answers is "wrong".

On Wednesday, August 5, 2020 at 12:59:01 PM UTC-6, rjf wrote:
>
> There are two square roots.  In this (classic) integration example/bug, a 
> choice has
> to be made.  You know that 4 has two square roots,  -2 and 2. 
> The integrand, which also can be rewritten as   sqrt ( 4-4*cos(x/2)^2) , 
> has 2 square roots.
> Therefore there are two potential different values for the integral.  Any 
> answer
> that supplies only one answer is wrong.
>
>
>
> On Tuesday, August 4, 2020 at 1:56:16 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> BTW :
>>
>> sage: integrate(sqrt(2-2*cos(x)),x, algorithm="fricas")
>> -2*(cos(x) + 1)*sqrt(-2*cos(x) + 2)/sin(x)
>> sage: integrate(sqrt(2-2*cos(x)),x, algorithm="mathematica_free")
>> -2*sqrt(-2*cos(x) + 2)*cot(1/2*x)
>>
>> Both are visually (on plot) and numerically correct ; both differentiate 
>> to expressions very hard to show equal to the original function.
>>
>> HTH,
>>
>> Le lundi 3 août 2020 10:50:12 UTC+2, Dima Pasechnik a écrit :
>>
>> This is a well-known bug in Sage. A workaround is to set the domain to 
>>> "real":
>>>
>>> sage: maxima_calculus.eval('domain: real');
>>> sage: integrate(sqrt(2-2*cos(x)),x,0,2*pi) # correct answer
>>> 8
>>>
>>> sage: maxima_calculus.eval('domain: complex'); # restore the state back
>>> sage: integrate(sqrt(2-2*cos(x)),x,0,2*pi) # now here the result is 
>>> again wrong, of course
>>> 0
>>>
>>>
>>> On Sun, Aug 2, 2020 at 5:26 PM Nico Guth  wrote:
>>>
 Hi,

 I discovered a bug, where a definite integral is calculated wrong!
 WolframAlpha result for comparison.

 Code:
 integrate(sqrt(2-2*cos(x)),x,0,2*pi)

 Also if I type show() instead of print() SageMathCell just doesn't show 
 anything.

 Also the form in which the indefinite integral is given is not very 
 pretty.
 WolframAlpha does a much better job simplifying.

 [image: sage_wrong_integral.png][image: 
 sage_wrong_integral_wolfram.png]
 [image: sage_wrong_integral_wolfram_2.png]

 -- 
 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-...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/487d0db8-5711-41a8-a7d4-1548286b5573n%40googlegroups.com
  
 
 .

>>> ​
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/34e4e9bb-cf9a-4276-8c9b-34bb78c0fd6bo%40googlegroups.com.

[sage-devel] Re: a problem with is_line_graph

[Dave Morris]

I think the bugfix in trac ticket #29740 
 fixes this problem, so the error 
should go away if you upgrade to the latest beta.  Please report again if 
it doesn't!  (Your example works fine for me in 9.2.beta5.)

On Friday, July 24, 2020 at 3:45:25 PM UTC-6, Martin R wrote:
>
> I think I stumbled over something slightly surprising.
>
> ┌┐
> │ SageMath version 9.2.beta1, Release Date: 2020-06-13   │
> │ Using Python 3.7.3. Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> sage: h = Graph([(0, 3), (0, 4), (1, 2), (1, 3), (1, 4), (2, 3), (2, 4)])
> sage: h.is_line_graph()
> ---
> Exception Traceback (most recent call last)
>  in ()
> > 1 h.is_line_graph()
>
> /home/martin/sage-develop/local/lib/python3.7/site-packages/sage/graphs/line_graph.pyx
>  
> in sage.graphs.line_graph.is_line_graph 
> (build/cythonized/sage/graphs/line_graph.c:2291)()
> 221 if g.is_connected():
> 222 try:
> --> 223 R, isom = root_graph(g)
> 224 if certificate:
> 225 return True, R, isom
>
> /home/martin/sage-develop/local/lib/python3.7/site-packages/sage/graphs/line_graph.pyx
>  
> in sage.graphs.line_graph.root_graph 
> (build/cythonized/sage/graphs/line_graph.c:7152)()
> 622 
> 623 if not is_isom:
> --> 624 raise Exception(error_message)
> 625 
> 626 return R, isom
>
> Exception: It looks like there is a problem somewhere. Youfound a bug here 
> ! Please report it on sage-devel,our google group !
> sage: 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2d2fe653-2319-4e6a-bf99-88b7941baf62o%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Dave Morris]

I think this last example is related to trac #27536 
<https://trac.sagemath.org/ticket/27536> (conversion of mathematical 
constant such as pi to RDF leaks memory).  There is still a memory leak 
(but smaller, I think) if pi^i is replaced with pi, but I don't see a 
memory leak if pi^i is replaced with RDF.pi().  I also don't see a leak 
with RDF.pi()^i, but I quickly get a RecursionError ("maximum recursion 
depth exceeded").  I know almost nothing about memory leaks, but I just 
wanted to point out that I noticed some related issues that might possibly 
provide an explanation (and certainly seem to be relevant to a complete 
solution).

On Thursday, July 23, 2020 at 3:39:09 PM UTC-6, Spencer Dembner wrote:
>
> It may be related, but I don't think it's exactly the same issue. For 
> example, the following, involving no square root, still leaks memory:
>
> for i in [1,..,2]:
> if i%100 == 0:
> print(i);
> print(get_memory_usage());
> C = continued_fraction(pi^i);
> C.denominator(100);
>
>
>
>
>
>
>
>
> On Thursday, July 23, 2020 at 4:27:46 PM UTC-5, Dave Morris wrote:
>>
>> Is this the issue that was reported in Trac #27185 
>> <https://trac.sagemath.org/ticket/27185> (defect: sqrt memory leak)?
>>
>> On Thursday, July 23, 2020 at 3:12:07 PM UTC-6, Spencer Dembner wrote:
>>>
>>> Yup- what you wrote gives me the same result as far as climbing memory 
>>> usage.
>>>
>>> On Thursday, July 23, 2020 at 4:07:23 PM UTC-5, vdelecroix wrote:
>>>>
>>>> Thanks for your report. 
>>>>
>>>> Actually, it does not seem to have much to do with continued 
>>>> fractions but rather with the symbolic ring 
>>>>
>>>> sage[4]: for i in [250,..,300]: 
>>>> ...: if i%1000 == 0: 
>>>> ...: print(i); 
>>>> ...: print(get_memory_usage()) 
>>>> ...: _ = RIF(sqrt(i)) 
>>>>
>>>> Le 23/07/2020 à 18:30, Spencer Dembner a écrit : 
>>>> > When using continued_fraction to compute denominators of continued 
>>>> fraction 
>>>> > convergents, I'm encountering what seems to be a memory leak. I'm 
>>>> running 
>>>> > SageMath 9.0 on Windows 10 64-bit. If I run the following, 
>>>> > 
>>>> > for i in [250,..,260]: 
>>>> >  if i%1000 == 0: 
>>>> >  print(i); 
>>>> >  print(get_memory_usage()); 
>>>> >  C = continued_fraction(sqrt(i)); 
>>>> >  C.denominator(100); 
>>>> > 
>>>> > then I see memory usage steadily climbing as I iterate through the 
>>>> loop. On 
>>>> > the other hand, if I initialize sqrt(i) as an algebraic number, 
>>>> memory 
>>>> > usage is essentially stable: 
>>>> > 
>>>> > for i in [250,..,260]: 
>>>> >  if i%1000 == 0: 
>>>> >  print(i); 
>>>> >  print(get_memory_usage()); 
>>>> >  if sqrt(i) not in QQ: 
>>>> >  K. = QuadraticField(i); 
>>>> >  C = continued_fraction(sqrti); 
>>>> >  C.denominator(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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/99c77db7-5eea-43e2-aa23-2f10dadfc8feo%40googlegroups.com.

Re: [sage-devel] continued_fraction seems to leak memory

[Dave Morris]

Is this the issue that was reported in Trac #27185 
 (defect: sqrt memory leak)?

On Thursday, July 23, 2020 at 3:12:07 PM UTC-6, Spencer Dembner wrote:
>
> Yup- what you wrote gives me the same result as far as climbing memory 
> usage.
>
> On Thursday, July 23, 2020 at 4:07:23 PM UTC-5, vdelecroix wrote:
>>
>> Thanks for your report. 
>>
>> Actually, it does not seem to have much to do with continued 
>> fractions but rather with the symbolic ring 
>>
>> sage[4]: for i in [250,..,300]: 
>> ...: if i%1000 == 0: 
>> ...: print(i); 
>> ...: print(get_memory_usage()) 
>> ...: _ = RIF(sqrt(i)) 
>>
>> Le 23/07/2020 à 18:30, Spencer Dembner a écrit : 
>> > When using continued_fraction to compute denominators of continued 
>> fraction 
>> > convergents, I'm encountering what seems to be a memory leak. I'm 
>> running 
>> > SageMath 9.0 on Windows 10 64-bit. If I run the following, 
>> > 
>> > for i in [250,..,260]: 
>> >  if i%1000 == 0: 
>> >  print(i); 
>> >  print(get_memory_usage()); 
>> >  C = continued_fraction(sqrt(i)); 
>> >  C.denominator(100); 
>> > 
>> > then I see memory usage steadily climbing as I iterate through the 
>> loop. On 
>> > the other hand, if I initialize sqrt(i) as an algebraic number, memory 
>> > usage is essentially stable: 
>> > 
>> > for i in [250,..,260]: 
>> >  if i%1000 == 0: 
>> >  print(i); 
>> >  print(get_memory_usage()); 
>> >  if sqrt(i) not in QQ: 
>> >  K. = QuadraticField(i); 
>> >  C = continued_fraction(sqrti); 
>> >  C.denominator(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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1da0986d-2243-4125-89ad-2a011be99dc7o%40googlegroups.com.

Re: [sage-devel] Error in Trac reports

[Dave Morris]

Report "{93} Active tickets I participated in (by time) (copy) 
" does not include the closed tickets 
(for me, at least).  I found this in the "Available Reports" link on trac.

On Sunday, July 5, 2020 at 4:47:40 PM UTC-6, Dima Pasechnik wrote:
>
>
>
> On Sun, 5 Jul 2020, 23:42 Paul Masson, > 
> wrote:
>
>> Report 51 (Active tickets I participated in / by time) includes closed 
>> tickets. Since these are available in report 54 (Tickets I've participated 
>> in, including closed / by time) the former should be adjusted to exclude 
>> them. Who has access to fix this? Thanks.
>>
>
> I have access, but no idea what happened, even less how to fix it. It 
> seems as if semantics of queries has changed after an update.
> Try making a custom query and see if you get meaningful results.
> Cc Erik, who used to be fixing trac.
>
> Dima
>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/390924b6-26d9-42f6-a57f-9ea4b8914694o%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0b338ce2-f1ab-4bce-b2e9-b43e3a251981o%40googlegroups.com.

[sage-devel] Re: [Bug] Possible Bug in FrobeniusMap for ntl finite fields of characteristic 2

[Dave Morris]

This bug is discussed in trac ticket #28617 
 (which recently received a patch).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/90133b60-c51a-47b7-ad5c-f2409f03b1a1o%40googlegroups.com.

[sage-devel] Re: Sage 9.1 - Possible bug in how matrices are treated in characteristic 2

[Dave Morris]

Thanks for your detailed report.  I confirm that your code crashes sage, so 
I opened trac ticket #29181  to 
address this issue.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f5ce5631-0715-48e5-9fb7-ca382d1d4e4bo%40googlegroups.com.

Re: [sage-devel] bug in matrix solve over inexact coefficients?

[Dave Morris]

Although both behaviors may be reasonable, I don't like the fact that each 
line of the following code gives a completely different result depending on 
whether F = RR (returns a result that may be garbage, without warning) or F 
= RDF (gives an error, even though there may be a valid solution).  My own 
preference for default behavior (for F = RR, at least, which is where I 
think a naive user is likely to be working) is intermediate between these 
two, and is what I think MATLAB does: return a result but give a warning. 

sage: matrix(F, [[0]]).solve_right(vector(F, [0]))
sage: matrix(F, [[0]]).solve_right(vector(F, [1]))

Along these lines, I note that the code for 
`Matrix_generic_dense.solve_right` has

try:
X = self._solve_right_nonsingular_square(C, check_rank=True)
except NotFullRankError:
X = self._solve_right_general(C, check=check)

It seems to me that the except clause would be a good place to put a 
warning message over inexact rings. However, I know nothing about numerical 
analysis (and not much about sage), so I am certainly not giving an expert 
opinion on anything in this discussion, just the viewpoint of this sage 
user, and I apologize if it is noise.

On Saturday, May 23, 2020 at 12:30:56 PM UTC-6, Markus Wageringel wrote:
>
> Indeed, instead of ignoring the `check` keyword altogether over inexact 
> fields, it would be useful to verify the solution when that is possible, 
> such as for exact input over SR and for ball and intervall fields. I have 
> opened #29729 <https://trac.sagemath.org/ticket/29729> for this. For 
> general inexact rings though, the result cannot be verified, so it would 
> not make sense to do the check by default.
>
>
> Am Samstag, 23. Mai 2020 07:15:45 UTC+2 schrieb Dave Morris:
>>
>> From the documentation at 
>> https://www.mathworks.com/help/matlab/ref/mldivide.html, it appears to 
>> me that MATLAB gives a warning: "Warning: Matrix is close to singular or 
>> badly scaled. Results may be inaccurate."  That seems to me to be a better 
>> default behavior than what sage is doing now, but I think it would make 
>> sense to let users choose to turn off the warning (and maybe also let them 
>> upgrade it to an error).
>>
>
>  The generic implementation of `solve_right` does not provide this. I 
> would suggest to use a type that has a specialized implementation for this, 
> such as RDF, CDF, CBF. For example over RDF and CDF, a warning is issued if 
> the input is ill-conditioned and an error is raised if the matrix is 
> singular, which is a reasonable behavior:
>
> sage: matrix(RDF, [[2/3, 1], [0.4, 0.6]]).solve_right(vector(RDF, [1, 1]))
> /Applications/SageMath/src/bin/sage-ipython:1: LinAlgWarning: Ill-conditioned 
> matrix (rcond=2.77556e-17): result may not be accurate.
>   #!/usr/bin/env sage-python
> (5404319552844596.0, -3602879701896396.0)
> sage: matrix(RDF, [[0]]).solve_right(vector(RDF, [1]))
> ...
> LinAlgError: Matrix is singular.
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/748c6d4f-bb2d-4c44-92c5-ddffbb02b475%40googlegroups.com.

Re: [sage-devel] bug in matrix solve over inexact coefficients?

[Dave Morris]

>From the documentation at 
https://www.mathworks.com/help/matlab/ref/mldivide.html, it appears to me 
that MATLAB gives a warning: "Warning: Matrix is close to singular or badly 
scaled. Results may be inaccurate."  That seems to me to be a better 
default behavior than what sage is doing now, but I think it would make 
sense to let users choose to turn off the warning (and maybe also let them 
upgrade it to an error).

On Friday, May 22, 2020 at 9:20:00 PM UTC-6, Michael Orlitzky wrote:
>
> On 5/22/20 6:40 PM, AlexGhitza wrote: 
> > I would also argue that, despite the validity of the arguments regarding 
> > inexact rings, this is a change in behavior that would have benefited 
> > from a deprecation warning for a short while. 
>
> We were pretty careful not to break anything in the sage library. For 
> typical inexact rings, the risk of breakage was minimal, because not 
> much worked to begin with. What we overlooked was that not all inexact 
> rings are typical, and that in cases like RealBallField and exact-SR, 
> the change could turn a right answer to a wrong one *in a situation that 
> wasn't ridiculous to begin with.* None of those cases were doctested, so 
> they were easy to overlook. 
>
>
> > Another user-friendlier way of doing this (making the check argument 
> > irrelevant in the inexact case) would have been to display a warning 
> > when the user asks for check=True in the inexact case, rather than 
> > simply ignoring it. 
>
> The base class defaults to check=True, and that can't be changed, so you 
> would get a warning on every inexact solve in that case. Moreover for 
> the "usual" inexact rings, things were unilaterally improved and not 
> deserving of a warning. 
>
> It will probably take a bit of domain-specific knowledge to make RBF/CBF 
> work as Nils expects, but reverting SR back to the old behavior when all 
> of its elements are exact shouldn't be hard if it doesn't cause any new 
> unforeseen problems. Let's just fix it instead of throwing warnings. 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e0969a6d-fc9d-457d-be3a-5413a1e23b4c%40googlegroups.com.

[sage-devel] Re: bug in matrix solve over inexact coefficients?

[Dave Morris]

This is the expected behavior after trac #12406 
. The OUTPUT section of the 
docstring of solve_right says "... If the system is not square or does not 
have full rank, then a solution is attempted via other means. For example, 
over "RDF" or "CDF" a least-squares solution is returned..."

This makes sense, since testing for the existence of a solution over 
inexact rings is problematic, but I do think it would be better if the 
method could have some some reasonable test available, even if it is not 
the default.

On Thursday, May 21, 2020 at 6:44:09 PM UTC-6, AlexGhitza wrote:
>
> Hi,
>
> I'm observing the following with version 9.1 (but not with 9.0 where the 
> behavior is correct):
>
> sage: m = matrix(SR, [0])
> sage: b = vector([1])
> sage: m.solve_right(b)
> (0)
>
> This should of course raise
>
> ValueError: matrix equation has no solutions
>
>
> It seems to be specific to inexact coefficients (the same problem occurs 
> for RR and CC, but not for QQ).
>
>
> Best,
> Alex
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/97809a44-17eb-4f2f-ba87-ea055c6c13a2%40googlegroups.com.

[sage-devel] Re: Quadratic Residual Bug?

[Dave Morris]

Here is a simple function that you could use for input of reasonable size. 
But this discussion is no longer about sagemath development, so please ask 
further questions about this at ask.sagemath.org

def is_quadratic_residue(a,n):
 return(mod(a,n).sqrt() in ZZ)

On Wednesday, May 6, 2020 at 10:08:16 PM UTC-6, Taylor Huang wrote:
>
> I see. But then, how should we determine quadratic residuosity in Sage? 
> (for tractible inputs)
>  
>
>> I don't think this is evidence of a bug, because t2 is not prime.  It is 
>> only when n is is an odd prime that kronecker(a,n) tells you whether a is a 
>> quadratic residue. See the wikipedia article on Kronecker symbol 
>> .
>>
>> On Wednesday, May 6, 2020 at 1:37:12 PM UTC-6, Taylor Huang wrote:
>>>
>>> As the attachment shown. kronecker(-1,t2) returns 1, but 
>>> mod(-1,t2).sqrt() says the square root cannot be done.
>>> It seems to be a bug.
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/15685258-9262-4ccb-a8e9-72ce0f0e328e%40googlegroups.com.

[sage-devel] Re: Quadratic Residual Bug?

[Dave Morris]

I don't think this is evidence of a bug, because t2 is not prime.  It is 
only when n is is an odd prime that kronecker(a,n) tells you whether a is a 
quadratic residue. See the wikipedia article on Kronecker symbol 
.

On Wednesday, May 6, 2020 at 1:37:12 PM UTC-6, Taylor Huang wrote:
>
> As the attachment shown. kronecker(-1,t2) returns 1, but mod(-1,t2).sqrt() 
> says the square root cannot be done.
> It seems to be a bug.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/67f3a387-e5f9-40a2-a5a6-cefe62a17602%40googlegroups.com.