Re: [sage-devel] Re: classifying trac tickets as silently incorrect results

[Jakob Kroeker]

using a keyword  the ticket will not added to the list of mathematically 
wrong answers.

It is about make silent wrong answers _visible_. Stopgaps are an  extreme 
tool and are hard to enforce.

Also I do not (yet) have the time to create 72 stopgaps and nobody else 
seems to care. 


Jakob


Am Sonntag, 10. Juli 2016 00:32:57 UTC+2 schrieb vdelecroix:
>
> On 09/07/16 18:17, Jakob Kroeker wrote: 
> > 
> >> 
> >> Please don't. That field is suppose to be used for tickets which 
> implement 
> >> the stopgap when it is applicable 
> > 
> > 
> > Unfortunately stopgaps for all the silent wrong results will hardly be 
> > accepted. 
> > I already experienced heavy opposition as I created some and was not 
> able 
> > to create them in full extent. 
> > 
> > With labels on issues with silently wrong answers we will have at least 
> an 
> > up-to date list of them: 
> > https://trac.sagemath.org/wiki/TicketReports 
>
> If it is just a matter of classification then you could add a keyword 
> instead of using stopgap which is meant for something else. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: classifying trac tickets as silently incorrect results

[Vincent Delecroix]

On 09/07/16 18:17, Jakob Kroeker wrote:




Please don't. That field is suppose to be used for tickets which implement
the stopgap when it is applicable



Unfortunately stopgaps for all the silent wrong results will hardly be
accepted.
I already experienced heavy opposition as I created some and was not able
to create them in full extent.

With labels on issues with silently wrong answers we will have at least an
up-to date list of them:
https://trac.sagemath.org/wiki/TicketReports


If it is just a matter of classification then you could add a keyword 
instead of using stopgap which is meant for something else.


--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: classifying trac tickets as silently incorrect results

[Jakob Kroeker]

>
> Please don't. That field is suppose to be used for tickets which implement 
> the stopgap when it is applicable


Unfortunately stopgaps for all the silent wrong results will hardly be 
accepted.
I already experienced heavy opposition as I created some and was not able 
to create them in full extent.

With labels on issues with silently wrong answers we will have at least an 
up-to date list of them:
https://trac.sagemath.org/wiki/TicketReports

And of course it is possible to create all the stopgaps afterwards.

Jakob


Am Samstag, 9. Juli 2016 21:00:58 UTC+2 schrieb Travis Scrimshaw:
>
>
> If a ticket describes an issue where sage silently returns a wrong answer, 
>> please update the ticket description, adding a 'wrongAnswerLabel'  to the 
>> stopgap field.
>>
>> Please don't. That field is suppose to be used for tickets which 
> implement the stopgap when it is applicable (which it would be good for you 
> to create and implement said stopgaps).
>
> Best,
> Travis
>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] please review bug fix #20513

[Vincent Delecroix]

Hello,

I did a bugfix in #20513 that was requested on sage-support (I consider 
this as an up-vote ;-). But no reviewer is on it. I would be delighted 
if somebody would take two minutes for the review.


Vincent

--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: classifying trac tickets as silently incorrect results

[Travis Scrimshaw]

> If a ticket describes an issue where sage silently returns a wrong answer, 
> please update the ticket description, adding a 'wrongAnswerLabel'  to the 
> stopgap field.
>
> Please don't. That field is suppose to be used for tickets which implement 
the stopgap when it is applicable (which it would be good for you to create 
and implement said stopgaps).

Best,
Travis

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] classifying trac tickets as silently incorrect results

[Jakob Kroeker]

Hello,


today in my spare free time I continued looking for tickets with describes 
issues where sage silently returns a wrong answer and stopped at
https://trac.sagemath.org/ticket/15325


For the following tickets I'm not sure, 

if they should be classified as 'silently incorrect result' or not


https://trac.sagemath.org/ticket/13321
https://trac.sagemath.org/ticket/13655

https://trac.sagemath.org/ticket/13707
https://trac.sagemath.org/ticket/13776

https://trac.sagemath.org/ticket/13758
https://trac.sagemath.org/ticket/14012
https://trac.sagemath.org/ticket/14069
https://trac.sagemath.org/ticket/14125
 https://trac.sagemath.org/ticket/14274
https://trac.sagemath.org/ticket/14277
https://trac.sagemath.org/ticket/14590
https://trac.sagemath.org/ticket/14735
https://trac.sagemath.org/ticket/14736
https://trac.sagemath.org/ticket/14738
https://trac.sagemath.org/ticket/14889
https://trac.sagemath.org/ticket/15114
https://trac.sagemath.org/ticket/15153



If a ticket describes an issue where sage silently returns a wrong answer, 
please update the ticket description, adding a 'wrongAnswerLabel'  to the 
stopgap field.



Jakob



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Is the glass half-full or half-empty ? Pick a standard.

[kcrisman]

On Saturday, July 9, 2016 at 12:37:15 PM UTC-4, Jakob Kroeker wrote:
>
> I think backward compatibility is a strong argument to keep returning True.
>>
>
> well, there is also the option to deprecate the is_connected() function 
> for the empty graph
> and then change the behaviour after a year.
>
> By the way, what about defining that the empty graph is connected AND 
> disconnected.
> ( I'm joking :-) )
>

Why not?  A set can be open and closed :-) which is a perfect occasion to 
recall the hilarious (if not quite SFW):
https://www.youtube.com/watch?v=SyD4p8_y8Kw

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Should RR coerce into RIF?

[Jakob Kroeker]

the ticket https://trac.sagemath.org/ticket/15114 seems orphan now...

Am Donnerstag, 20. März 2014 12:58:30 UTC+1 schrieb Marco Streng:
>
> Thanks for all the replies. It seems that everybody here agrees to 
> disallow coercions from RR to RIF, which is all that ticket 
> http://trac.sagemath.org/ticket/15114 is about, so that ticket can 
> proceed. 
>
> As for conversions or coercions RIF to RR, there doesn't seem to be 
> anybody strongly in favour having them, and it is not clear how it 
> should work, so I won't touch them. 
>
>
>
>
> 2014-03-19 16:39 GMT+01:00 Robert Bradshaw  >: 
> > +1 to all of this, specifically 
> > 
> > 1) allow 
> > 2) allow for point intervals (maybe) 
> > 3)  dissallow 
> > 
> > On Tue, Mar 18, 2014 at 3:02 PM, David Roe  > wrote: 
> >> Marc Mezzarobba wrote: 
> >>>Marco Streng wrote: 
>  So the choices are: 
>  
>  1) explicit conversion RR --> RIF: allow / disallow 
>  2) explicit conversion RIF --> RR: allow / disallow 
>  3) automatic coercisions: disallow / (RR-->RIF) / (RIF-->RR) 
> >>>[...] 
> >> 
>  My vote is: 
>  1) allow 
>  2) allow 
>  3) from RIF to RR 
> >>> 
> >>>Mine is: 
> >>> 1) allow 
> >> 
> >>> 2) allow for point intervals, require the use of explicit method calls 
> >>>(e.g., center()) for general intervals 
> >>> 3) disallow (but see below) 
> >>> 
> >>> Regarding 3), and in response to Thomas Coffee's arguments, I would be 
> >> 
> >>> in favor of also having "non-rigorous intervals", living in a separate 
> >>> parent, with a coercion from RR. In fact, one also needs intervals 
> with 
> >>> integer, rational or even symbolic endpoints from time to time. So 
> >>> unless I'm missing something, these "non-rigorous interval" could 
> simply 
> >>> be the elements of Intervals(RR), where Intervals(C) would work for 
> more 
> >>> or less arbitrary C. (And there could perhaps be a coercion from RIF 
> to 
> >>> Intervals(RR), but certainly not in the other direction.) 
> >> 
> >> I agree with Marc, though I note that C needs at least a partial 
> ordering, 
> >> which most rings don't come with. 
> >> 
> >> On Tue, Mar 18, 2014 at 2:16 PM, Thierry  > 
> >> wrote: 
> >>> 
> >>> 
> >>> It seems there are more precise cases to consider: 
> >>> 
> >>> - How do you plan to coerce a RIF element with non-trivial diameter to 
> a 
> >>>   RR element ? 
> >> 
> >> 
> >> I would say you don't even allow conversion in this case, let alone 
> >> coercion. 
> >> 
> >>> 
> >>> - How do you plan to convert 
> >>>   - from RealIntervalField(2) to RealField(100) ? 
> >> 
> >> If you start with a point interval, there's no problem.  Otherwise, 
> >> disallowed. 
> >>> 
> >>>   - from RealIntervalField(100) to RealField(2) ? 
> >> 
> >> Conversion should work as long as the upper and lower endpoints are the 
> same 
> >> in RealField(2). 
> >>> 
> >>>   - from RealField(100) to RealIntervalField(2) ? 
> >> 
> >> Smallest interval containing the input. 
> >>> 
> >>>   - from RealField(2) to RealIntervalField(100) ? 
> >> 
> >> Here you can use a point interval as the image. 
> >> 
> >> Of course, none of these should be coercions. 
> >> 
> >>> 
> >>> - How do you mix both (do you plan to deal with possible compensations 
> >>>   between number of bits of precision of the field and the diameter of 
> >>>   the intervals) ? 
> >> 
> >> 
> >> I would say yes: you can mix a change in precision with a change in 
> >> precision type. 
> >> 
> >>> 
> >>> For example, in which case do you allow (silent) coercion, and what 
> >>> should be the result of the (explicit) conversion: 
> >>> 
> >>> - RIF(-1,1) -> RR 
> >> 
> >> Coercion and conversion should both fail. 
> >>> 
> >>> - RealIntervalField(100)(1.1,1.2)) -> RealField(2) 
> >> 
> >> Coercion and conversion should both fail. 
> >>> 
> >>> - RealField(2)(pi) -> RIF  [which diameter, which endpoints ?] 
> >> 
> >> A point interval (3.0, 3.0) 
> >>> 
> >>> 
> >>> 
> >>> As for me, 
> >>> - it is clear that RIF(pi) should be coerced to RR(pi) 
> >> 
> >> I think that this actually isn't clear, since RIF(pi) is not a point 
> >> interval.  Of course, we could make a special case when the length of 
> the 
> >> interval is the minimum possible, and use the rounding mode of RR to 
> >> determine which endpoint to pick (though I don't know what we should do 
> in 
> >> the default 'RNDN' 
> >>> 
> >>> - i agree with coercing from x in RealIntervalField(a) to RealField(b) 
> >>>   when the endpoints of x are the same in RealField(b) 
> >> 
> >> Coercion needs to be defined on the whole domain.  This rule works for 
> >> conversion though. 
> >>> 
> >>> - i have no problem for explicit conversion from RIF(-1,1) to RR, but 
> it 
> >>>   should be well specified in the doc, since there is no canonical 
> way. 
> >> 
> >> I think it should be disallowed, since there are already functions to 
> get 
> 

Re: [sage-devel] Re: Is the glass half-full or half-empty ? Pick a standard.

[Jakob Kroeker]

>
> I think backward compatibility is a strong argument to keep returning True.
>

well, there is also the option to deprecate the is_connected() function for 
the empty graph
and then change the behaviour after a year.

By the way, what about defining that the empty graph is connected AND 
disconnected.
( I'm joking :-) )

But seriously, I just thought, what about dropping the definition for graph 
connectedness at all.
and introduce three different cases instead:

- a graph has 0 components
- a graph has exactly 1 component
- a graph has 2 or more components

At least we are able to count ;-)


I think If we cannot handle special cases consistently even in theory, we 
will never ever be able to implement it without getting tons of worms...

Jakob

Am Donnerstag, 22. August 2013 23:29:45 UTC+2 schrieb Stefan:
>
> I think backward compatibility is a strong argument to keep returning True.
>
> I also have an answer based on "my favorite definition is ...", namely the 
> analogue with matroid connectivity, where any matroid that is too small to 
> have a k-separation, is automatically k-connected. Extending this to 
> graphs, the empty graph should be infinitely connected.
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Trac again...

[Travis Scrimshaw]

On Friday, July 8, 2016 at 3:39:59 AM UTC-5, Jori Mäntysalo wrote:
>
> What is wrong with https://trac.sagemath.org/ticket/20980 ? 
>
> The branch field is red, but I think I did nothing unusual. Also I got an 
> error message about mails not sent when setting it to needs_review. 
>
>
>
Also, the automerging on trac has been known to be less permissive than 
local versions of git.

Best,
Travis

 

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.