Re: [sage-support] bug in plot?

[kcrisman]

I'd think that matplotlib's defaults are defaults for a good reason.


Agreed, but not a good *mathematical* reason. It is a good *data analysis* 
reason (appropriate for mpl), which is not the same thing.  I can't think 
of a single mathematics textbook, talk, or other purely mathematical 
setting in which I've ever seen an offset of that type.  Axes are always 
when the variables = 0, end of story.
 

I'd rather add a note in the docs saying how to change this option.



Naturally, we can do that anyway, and in fact should include several 
examples of the type of usage where that would be helpful. 

Nonetheless, especially since Sage does not seem to be used very heavily 
for data applications (pandas, numpy, or others long since filling that 
gap), I would also recommend changing that default.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/95d368bb-9fb3-42ec-b1d5-96fe457f790bn%40googlegroups.com.

Re: [sage-support] bug in plot?

[Dima Pasechnik]

On Fri, Mar 15, 2024 at 9:44 PM Nils Bruin  wrote:

> On Friday 15 March 2024 at 12:42:49 UTC-7 kcrisman wrote:
>
> Or rather, should the default be useoffset False?
>
>
> Yes, I think that would be reasonable to do. Clearly, offsets being used
> without the user knowing they exist can easily lead to confusion and
> misinterpreting the graph, as had been demonstrated here. With the default
> off, the user would get an ugly graph. If they want to improve it, they
> would hopefully read the documentation. If we document "useoffset" then the
> user could find it there.
>

I'd think that matplotlib's defaults are defaults for a good reason.
I'd rather add a note in the docs saying how to change this option.


> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-support/24d2b075-0b6f-40f2-8170-67d7a2b36c36n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/CAAWYfq1Ov9bZ52g56qJ_HbV%2B6SuhroQ6Z0k8%3DPN7J0aNoBMt0w%40mail.gmail.com.

Re: [sage-support] Antisymmetry Definition in SageMath for DiGraphs

[Dima Pasechnik]

This is now https://github.com/sagemath/sage/issues/37618

On Sat, Mar 16, 2024 at 12:42 PM Dima Pasechnik  wrote:

> Dear Hellen, dear Nils,
>
> On Fri, Mar 15, 2024 at 11:51 PM Nils Bruin  wrote:
>
>> On Friday 15 March 2024 at 15:08:34 UTC-7 Hellen Colman wrote:
>>
>> Let me just clarify the main point of his question just in case we can
>> still obtain a helpful answer. Essentially the question is: Why is Sage
>> calling "antisymmetric" to a property that is not the standard
>> antisymmetric property?
>>
>>
>> I agree that a relation gives rise to a graph, but I wouldn't presume
>> that the standard notion of "antisymmetric" for relations would agree with
>> that on graphs (or even that there would be a property of graphs that is
>> called "antisymmetric).  So if there is something transferable to be
>> learned for for students here it is perhaps that terminology is not
>> perfectly aligned between different areas in mathematics. Given that the
>> word "antisymmetric" is now taken to mean something specific for graphs (I
>> assume whoever did that consulted some graph-theory books), it will have
>> considerable inertia because changing it to something else would break
>> backward compatibility.
>>
>
> I went to look for some references for "antisymmetric graph", and indeed
> Sage's definition
> doesn't agree with what I found:
>  and
> 
>
> I dug up the original vintage commit where this function was introduced:
> (fortunately, with git it's just
>git log -S "def antisymmetric(self)"
> )
> commit 0e4f3807f2a18b3a03f47ad35d0aae1c06058fc0
> Author: Jason Grout 
> Date:   Tue Sep 25 18:46:29 2007 -0500
>
> graphs: added transitive_closure() and antisymmetric().
> [...]
> +def transitive_closure(self):
> +r"""
> +Modifies a graph to be its transitive closure and returns the
> +modified graph.
> [...]
> +def antisymmetric(self):
> +r"""
> +Returns True if the relation given by the graph is
> +antisymmetric and False otherwise.
> +
> +A graph represents an antisymmetric relation if there being a
> +path from a vertex x to a vertex y implies that there is not a
> +path from y to x unless x=y.
> [...]
>
> That is, "antisymmetric" was just a sloppy naming for a different to
> "antisymmetric graph".
>
> I propose the following course of action:
>
> 1) copy antisymmetric() to antisymmetric_relation(); deprecate
> antisymmetric();
> introduce  antisymmetric_graph(), to mean the standard definition as
> Hellen points at.
> 2) after the deprecation period, make antisymmetric() a copy of
> antisymmetric_graph(),
> and deprecate the latter
> 3) after the (2nd) deprecation period, remove antisymmetric_graph()
> So in the end, in about 2 years, there will be antisymmetric() -
> conforming to the standard - and antisymmetric_relation()
> - the original code for old antisymmetric()
>
> Cheers
> Dima
>
>
>> If you feel strongly that a change in terminology would be beneficial,
>> you could collect some references corroborating your proposed meaning. If
>> someone else feels strongly enough about preserving the present meaning,
>> they would likely counter with their own set of references. At that point
>> hopefully a consensus would grow, with a (slight) preference for the status
>> quo. If both notions have support, we'd likely look into a way of
>> supporting both; probably by dangling the appropriate adjectives in front
>> of "antisymmetric", like "edge_antisymmetric" and "path_antisymmetric" or
>> something like that.
>>
>> For your research, you might be interested in an
>> is_homotopically_equivalent method.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-support+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-support/8b537b0f-d1bb-41eb-95f6-33c8a2c4c3d6n%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/CAAWYfq2YvkNOCO2TK1Ta-q1ZdfJX%3DR5iC_sLsuOKtmRy%3DYHmMQ%40mail.gmail.com.

Re: [sage-support] Antisymmetry Definition in SageMath for DiGraphs

[Dima Pasechnik]

Dear Hellen, dear Nils,

On Fri, Mar 15, 2024 at 11:51 PM Nils Bruin  wrote:

> On Friday 15 March 2024 at 15:08:34 UTC-7 Hellen Colman wrote:
>
> Let me just clarify the main point of his question just in case we can
> still obtain a helpful answer. Essentially the question is: Why is Sage
> calling "antisymmetric" to a property that is not the standard
> antisymmetric property?
>
>
> I agree that a relation gives rise to a graph, but I wouldn't presume that
> the standard notion of "antisymmetric" for relations would agree with that
> on graphs (or even that there would be a property of graphs that is called
> "antisymmetric).  So if there is something transferable to be learned for
> for students here it is perhaps that terminology is not perfectly aligned
> between different areas in mathematics. Given that the word "antisymmetric"
> is now taken to mean something specific for graphs (I assume whoever did
> that consulted some graph-theory books), it will have considerable inertia
> because changing it to something else would break backward compatibility.
>

I went to look for some references for "antisymmetric graph", and indeed
Sage's definition
doesn't agree with what I found:
 and


I dug up the original vintage commit where this function was introduced:
(fortunately, with git it's just
   git log -S "def antisymmetric(self)"
)
commit 0e4f3807f2a18b3a03f47ad35d0aae1c06058fc0
Author: Jason Grout 
Date:   Tue Sep 25 18:46:29 2007 -0500

graphs: added transitive_closure() and antisymmetric().
[...]
+def transitive_closure(self):
+r"""
+Modifies a graph to be its transitive closure and returns the
+modified graph.
[...]
+def antisymmetric(self):
+r"""
+Returns True if the relation given by the graph is
+antisymmetric and False otherwise.
+
+A graph represents an antisymmetric relation if there being a
+path from a vertex x to a vertex y implies that there is not a
+path from y to x unless x=y.
[...]

That is, "antisymmetric" was just a sloppy naming for a different to
"antisymmetric graph".

I propose the following course of action:

1) copy antisymmetric() to antisymmetric_relation(); deprecate
antisymmetric();
introduce  antisymmetric_graph(), to mean the standard definition as Hellen
points at.
2) after the deprecation period, make antisymmetric() a copy of
antisymmetric_graph(),
and deprecate the latter
3) after the (2nd) deprecation period, remove antisymmetric_graph()
So in the end, in about 2 years, there will be antisymmetric() - conforming
to the standard - and antisymmetric_relation()
- the original code for old antisymmetric()

Cheers
Dima


> If you feel strongly that a change in terminology would be beneficial, you
> could collect some references corroborating your proposed meaning. If
> someone else feels strongly enough about preserving the present meaning,
> they would likely counter with their own set of references. At that point
> hopefully a consensus would grow, with a (slight) preference for the status
> quo. If both notions have support, we'd likely look into a way of
> supporting both; probably by dangling the appropriate adjectives in front
> of "antisymmetric", like "edge_antisymmetric" and "path_antisymmetric" or
> something like that.
>
> For your research, you might be interested in an
> is_homotopically_equivalent method.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-support/8b537b0f-d1bb-41eb-95f6-33c8a2c4c3d6n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/CAAWYfq37mWomXYd2eRS3MB4oqisaJLskgrZhrSqKP%3DjTHNazrA%40mail.gmail.com.