[sage-devel] Re: Question about deprecation warnings: when do they appear in doctests vs. real life?

[Simon King]

Hi David,

On 2019-10-19, David Roe  wrote:
> I think the idea is that if a user's typing interactively then they don't
> need a deprecation warning (since the behavior currently works).  It's more
> important to show a user a warning if they have the deprecated behavior in
> a function they've written.

I don't like that idea. If they write code, I suppose many people
test their code in an interactive session while writing it. So, it would
be fair to show them during the interactive session that the code
they're about to write is deprecated.

Best regards,
Simon

-- 
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/qoh6qq%2439ev%241%40blaine.gmane.org.

[sage-devel] Re: quadratic forms signature_vector() gives different results for real cyclotomics and for reals

[Simon Brandhorst]

Dear Ignat Soroko,

the quadratic forms code was written with quadratic forms over QQ and over 
ZZ in mind. So I would be very sceptic about any functionality over number 
fields. 
For instance the signature vector you mention does not make sense of the 
F. =CyclotomicField(8). Instead of a single signature vector, over a 
number field you should 
obtain a signature for each real embedding F. Since F has no real places it 
does not really have signatures. All infinite places are complex and all 
regular quadratic forms over CC are equivalent. So basically 

sage: 
Q=QuadraticForm(K,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0,
: 0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
sage: Q.signature_vector()

should either raise a value error, or 
be called signature_vectors() and return a dictionary of real places and 
signature vectors. 

Best,
Simon

On Friday, October 18, 2019 at 2:12:02 AM UTC+2, Ignat Soroko wrote:
>
> I am computing the signature of a quadratic form having entries 0, 1, 
> -1/2, -sqrt(2)/2. I noticed that the result of signature_vector() is 
> different if we treat the number sqrt(2) as a cyclotomic or as a real 
> number. Please look at the example:
>
> sage: K.=CyclotomicField(8)
> sage: a=z-z^3  # a is a square root of 2
> sage: a-sqrt(2)
> 0
> sage: 
> Q=QuadraticForm(K,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0,
> : 0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
> sage: Q.signature_vector()
> (8, 0, 0)
>
> this cannot be true since there exists an isotropic vector:
>
> sage: v=vector([1,a,1,0,0,0,0,0])
> sage: v*Q.matrix()*v
> 0
>
> Let's try it over reals:
>
> sage: a=sqrt(2)
> sage: 
> Q=QuadraticForm(RR,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0
> : ,0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
> sage: Q.signature_vector()
> (6, 2, 0)
>
> however, the isotropic vector above is not isotropic anymore:
>
> sage: v=vector([1,a,1,0,0,0,0,0])
> sage: v*Q.matrix()*v
> sqrt(2)*(1.00*sqrt(2) - 1.41421356237310) - 
> 1.41421356237310*sqrt(2) + 2.00
>
> I also tried to define 
>
> sage: a=sqrt(AA(2))
> sage: 
> Q=QuadraticForm(AA,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0
> : ,0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
>
> but Q.signature_vector() gives a runtime error with many lines of code 
> ending in:
>
> RuntimeError: maximum recursion depth exceeded
>
>
> Questions:
> 1) is Q.signature_vector() over cyclotomic field is interpreted in some 
> other way than for reals, thus making the result (8,0,0) somehow correct?
>
> 2) Which setting would guarantee both the correct result for 
> signature_vector() using the exact arithmetic and at the same time show 
> that v is actually an isotropic vector?
>
> Thank you!
>
>
>
>

-- 
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/edce4769-1ca3-4400-bd50-ef01f0a11d5c%40googlegroups.com.

Re: [sage-devel] Re: quadratic forms signature_vector() gives different results for real cyclotomics and for reals

[Dima Pasechnik]

On Sun, 20 Oct 2019 at 11:38, Simon Brandhorst  wrote:

> Dear Ignat Soroko,
>
> the quadratic forms code was written with quadratic forms over QQ and over
> ZZ in mind. So I would be very sceptic about any functionality over number
> fields.
> For instance the signature vector you mention does not make sense of the
> F. =CyclotomicField(8). Instead of a single signature vector, over a
> number field you should
> obtain a signature for each real embedding F. Since F has no real places
> it does not really have signatures. All infinite places are complex and all
> regular quadratic forms over CC are equivalent. So basically
>
> sage:
> Q=QuadraticForm(K,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0,
> : 0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
> sage: Q.signature_vector()
>
> should either raise a value error, or
> be called signature_vectors() and return a dictionary of real places and
> signature vectors.
>

I thought at some point it was agreed that it makes sense for number fields
to come with a default embedding. Is this already the case? Otherwise the
meaning of sign() is not clear...
There is also a possibility of the signature being the same for every
embedding, at least for a class of forms.


>
> Best,
> Simon
>
> On Friday, October 18, 2019 at 2:12:02 AM UTC+2, Ignat Soroko wrote:
>>
>> I am computing the signature of a quadratic form having entries 0, 1,
>> -1/2, -sqrt(2)/2. I noticed that the result of signature_vector() is
>> different if we treat the number sqrt(2) as a cyclotomic or as a real
>> number. Please look at the example:
>>
>> sage: K.=CyclotomicField(8)
>> sage: a=z-z^3  # a is a square root of 2
>> sage: a-sqrt(2)
>> 0
>> sage:
>> Q=QuadraticForm(K,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0,
>> : 0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
>> sage: Q.signature_vector()
>> (8, 0, 0)
>>
>> this cannot be true since there exists an isotropic vector:
>>
>> sage: v=vector([1,a,1,0,0,0,0,0])
>> sage: v*Q.matrix()*v
>> 0
>>
>> Let's try it over reals:
>>
>> sage: a=sqrt(2)
>> sage:
>> Q=QuadraticForm(RR,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0
>> : ,0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
>> sage: Q.signature_vector()
>> (6, 2, 0)
>>
>> however, the isotropic vector above is not isotropic anymore:
>>
>> sage: v=vector([1,a,1,0,0,0,0,0])
>> sage: v*Q.matrix()*v
>> sqrt(2)*(1.00*sqrt(2) - 1.41421356237310) -
>> 1.41421356237310*sqrt(2) + 2.00
>>
>> I also tried to define
>>
>> sage: a=sqrt(AA(2))
>> sage:
>> Q=QuadraticForm(AA,8,[1/2,-a/2,0,0,0,0,0,0,1/2,-a/2,0,0,0,0,0,1/2,-1/2,0,0
>> : ,0,0,1/2,-1/2,0,0,0,1/2,-1/2,0,0,1/2,-a/2,0,1/2,-a/2,1/2])
>>
>> but Q.signature_vector() gives a runtime error with many lines of code
>> ending in:
>>
>> RuntimeError: maximum recursion depth exceeded
>>
>>
>> Questions:
>> 1) is Q.signature_vector() over cyclotomic field is interpreted in some
>> other way than for reals, thus making the result (8,0,0) somehow correct?
>>
>> 2) Which setting would guarantee both the correct result for
>> signature_vector() using the exact arithmetic and at the same time show
>> that v is actually an isotropic vector?
>>
>> Thank you!
>>
>>
>>
>> --
> 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/edce4769-1ca3-4400-bd50-ef01f0a11d5c%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/CAAWYfq0bENV2q-sTZ%3DbK47WS9ekP_LTAB_AWd3NB2TH3OeD2Qg%40mail.gmail.com.

Re: [sage-devel] Re: Question about deprecation warnings: when do they appear in doctests vs. real life?

[David Roe]

I don't mind changing the behavior, I was just trying to explain why it's
currently as is.  If we do make a change, we'll probably have to detect an
interactive session as a special case so that we can keep the current
behavior when called from a function.
David

On Sun, Oct 20, 2019 at 4:45 AM Simon King  wrote:

> Hi David,
>
> On 2019-10-19, David Roe  wrote:
> > I think the idea is that if a user's typing interactively then they don't
> > need a deprecation warning (since the behavior currently works).  It's
> more
> > important to show a user a warning if they have the deprecated behavior
> in
> > a function they've written.
>
> I don't like that idea. If they write code, I suppose many people
> test their code in an interactive session while writing it. So, it would
> be fair to show them during the interactive session that the code
> they're about to write is deprecated.
>
> Best regards,
> Simon
>
> --
> 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/qoh6qq%2439ev%241%40blaine.gmane.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAChs6_mZFtVT%2BH%2BzfrsYqqxmOQbm57%3DCJMMUWicaJjgFUhgdfw%40mail.gmail.com.

Re: [sage-devel] Re: Question about deprecation warnings: when do they appear in doctests vs. real life?

[Vincent Delecroix]

See

https://trac.sagemath.org/ticket/28500

Le 20/10/2019 à 08:36, David Roe a écrit :

I don't mind changing the behavior, I was just trying to explain why it's
currently as is.  If we do make a change, we'll probably have to detect an
interactive session as a special case so that we can keep the current
behavior when called from a function.
David

On Sun, Oct 20, 2019 at 4:45 AM Simon King  wrote:


Hi David,

On 2019-10-19, David Roe  wrote:

I think the idea is that if a user's typing interactively then they don't
need a deprecation warning (since the behavior currently works).  It's

more

important to show a user a warning if they have the deprecated behavior

in

a function they've written.


I don't like that idea. If they write code, I suppose many people
test their code in an interactive session while writing it. So, it would
be fair to show them during the interactive session that the code
they're about to write is deprecated.

Best regards,
Simon

--
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/qoh6qq%2439ev%241%40blaine.gmane.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1ce72b00-8067-0d41-67bc-2cbf7f0d8d0d%40gmail.com.

Re: [sage-devel] Question about deprecation warnings: when do they appear in doctests vs. real life?

[Vincent Delecroix]

Le 19/10/2019 à 13:19, David Roe a écrit :

I think the idea is that if a user's typing interactively then they don't
need a deprecation warning (since the behavior currently works).  It's more
important to show a user a warning if they have the deprecated behavior in
a function they've written.


I don't agree with this behavior at all. A user typically wants to know
whether her commands are future-proof. Typical situation: I want to show
a colleague how to do this and that in sage cell. Damn I have a
different version on my computer! The commands that run smoothly in my
console fail in the sage cell.

And note that many people write Sage scripts with no function at all
(e.g. in a Sage notebook, or in a .sage file).

--
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/94bceb36-a634-17c5-c780-97edede84653%40gmail.com.

Re: [sage-devel] Question about deprecation warnings: when do they appear in doctests vs. real life?

[Vincent Delecroix]

Le 20/10/2019 à 11:17, Vincent Delecroix a écrit :

Le 19/10/2019 à 13:19, David Roe a écrit :

I think the idea is that if a user's typing interactively then they don't
need a deprecation warning (since the behavior currently works).  It's 
more
important to show a user a warning if they have the deprecated 
behavior in

a function they've written.


I don't agree with this behavior at all. A user typically wants to know
whether her commands are future-proof. Typical situation: I want to show
a colleague how to do this and that in sage cell. Damn I have a
different version on my computer! The commands that run smoothly in my
console fail in the sage cell.

And note that many people write Sage scripts with no function at all
(e.g. in a Sage notebook, or in a .sage file).


Finally, whatever choice of behavior is made, it should be consistent
between Python and Cython. See

  https://trac.sagemath.org/ticket/28500

--
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/0724f70d-5547-5c48-7740-af339401e185%40gmail.com.

Re: [sage-devel] Question about deprecation warnings: when do they appear in doctests vs. real life?

[Nils Bruin]

On Saturday, October 19, 2019 at 1:20:15 PM UTC-7, David Roe wrote:
>
> I think the idea is that if a user's typing interactively then they don't 
> need a deprecation warning (since the behavior currently works).  It's more 
> important to show a user a warning if they have the deprecated behavior in 
> a function they've written.
>
 
I'm pretty sure that's not the reason. As you can see from 
https://trac.sagemath.org/ticket/28500, the stack depth is tuned so that 
the warning references the stack frame of the *call site* of the function 
raises the deprecation warning. That makes sense, because that's where the 
change should be made if you want to avoid calling a deprecated function. 
That works just fine from the interpreter top level, because there is a 
stack frame corresponding to top level.

The problem arises when the deprecation warning is raised in a cython 
function, since cython doesn't create python stack frames. With one less 
frame on the stack, the warning ends up referencing the level *above* the 
call site, which is there in the doctest framework, but not at top-level in 
the interpreter. In the doctest it means there's a nonsensical callsite 
referenced (but this is not checked by the doctests); in the interpreter it 
means the warning gets swallowed because a a failure in finding a stack 
frame [I think that behaviour is a bug in Python's warning machinery. It's 
a silent failure to issue a warning in a case where some warning is almost 
certainly desired].

The obvious solution is to use a different "deprecation" in cython code: 
one that uses a stack depth of one less. This is quite easy to implement by 
providing a "deprecation_cython" as well and use something like "from 
sage.misc.superseded import deprecation_cython as deprecation" in cython 
files instead of the usual. Making this change is quite straightforward (it 
can probably be done by a script if you really want to) and is completely 
uncontroversial. It is a bit of work, though, and it will be touching a lot 
of files.

-- 
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/9f02b869-2528-436e-96c3-dcabe792d32b%40googlegroups.com.