Re: [sage-devel] Giving Sage AI-based step-by-step equation solving abilities

[Ted Kosan]

Johan wrote:

> As William stated, I think any functionality improving SageMath's appeal
> for, say, educating high school students would be very welcome. My main
> concern is how valuable what you propose with PRESS-like printing is in
> this respect.
>
> You gave a printout of your current PRESS implementation earlier, for
> solving a simple linear equation in one variable. That printout is
> extremely verbose and very micro-syntactically oriented. My guess would
> be that few high school teachers would wish to teach the simple isolation of a
> variable technique that way.

Unfortunately, what most mathematics teachers are teaching is not
mathematics. This observation is described well by Scott Gray in the
following blog post excerpt (Scott was a university mathematics
professor, and he also designed and orchestrated the building of the
O'Reilly School of Technology):

http://patternmatics.org/temp/scott_gray.html

Here are some passages from this blog post:

"None of my students knew what they were talking about. Even students
who got perfect scores on my written exams didn't really understand
what it was that they were doing."

"...students were simply emulating calculation techniques, without
understanding where those techniques came from, or how to create them
themselves."

"...students would ask me to solve every type of problem they could
find in the textbook. Even though I'd have them try the problems
before showing them the solution, they were really preparing a
decision matrix for a matching game. If the problem was like this,
then they would do this; if it was like that then they'd do that, and
so on."


High school mathematics teachers are not qualified to decide how
mathematics should be taught because they don't know enough about how
mathematics actually works to be entrusted with this decision. In the
future, K-12 mathematics teachers will be replaced by AI mathematics
tutors. The software I am writing is being specifically designed for
this purpose.



> And students struggling with the technique
> would mostly just become more confused ("undefine the binary '-' operator",
> "change the association of +", etc.), and would fail building up
> mathematical intuition but rather focus on the syntax.

As Scott Gray's blog post indicates, the kind of mathematical
intuition that most students are being taught to build up is the wrong
kind of intuition. The right kind of mathematical intuition consists
of the techniques that PRESS uses. These techniques are very
syntax-oriented, but they are so simple and straightforward that even
young children should be able to learn them without too much
difficulty.

Before I started testing my solver with students, I was also concerned
that the rules it used might be too detailed for them. However, what I
discovered is that many students found the high level of detail to be
illuminating because for the first time in their lives they were
seeing how mathematics actually worked with nothing being hidden from
them.

Having said that, the set of rules that are shown in the demo video
are just the set I decided to experiment with first. The software can
be easily configured to work with other sets of rules, and it
shouldn't take too much effort to replace the rules shown in the demo
with fewer more abstract rules. It is going to be interesting to
discover which sets of rules are best suited for various educational
goals.



> In Denmark - and my impression is that the same goes for other countries
> as well - high school curriculum has largely moved away from solving of
> such equations using identities and "tricks". The cos(x+y) identities
> etc. and similar are not even taught anymore. In algebra, students
> mostly solve linear equations with 1 or 2 unknowns and second-degree
> equations. Simple isolation involving logs and exponentials, and there's
> also some simplification and/or factoring of e.g. polynomial fractions
> involved in function analysis.

Eventually I want to give my solver all of the abilities that PRESS
has. However, this is mostly from a personal desire to understand
everything there is to understand about how PRESS works. For most
students, I think the best use of PRESS-based software will probably
be for teaching them the fundamentals of how mathematics actually
works. After they are comfortable with this knowledge, and proficient
at using it, I think they should be taught how to program a
conventional CAS instead of being taught PRESS's more advanced
capabilities.

Ted

-- 
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: Finite fields coercion bug

[Nils Bruin]

On Thursday, October 13, 2016 at 12:16:36 PM UTC-7, John Cremona wrote:
>
> Kwankyu's point is also a good one.  It really is not acceptable (from 
> a user's point of view) to ask if there any coercions, be told there 
> are none, and then be prevented from defining one! 
>

It's a necessity for sanity, though: These parents are global objects, so 
they should be immutable in their behaviour. Once it has been decided there 
is no coercion to some existing object, it cannot happen that later on, 
such a coercion is available. That's observably mutated behaviour. It can 
also cause inconsistencies in the coercion discovery: the fact that a 
coercion was NOT found can have forced the construction and caching of a 
coercion elsewhere. This could be inconsistent with later discoveries if 
there is now a coercion found.

-- 
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: Finite fields coercion bug

[David Roe]

On Thu, Oct 13, 2016 at 5:09 PM, Kwankyu Lee  wrote:

> Hi David,
>
> First, thank you for technical explanations. They are compelling.
>
> On Thursday, October 13, 2016 at 9:59:50 PM UTC+2, David Roe wrote:
>>
>>
>> In order to create finite fields with arbitrary variable names that fit
>> into a lattice of fields, one possibility would be able to give an
>> algebraic closure explicitly as an argument to GF.  Is that what you're
>> suggesting?
>> sage: F = GF(3).algebraic_closure('custom')
>> sage: K9 = GF(9,'b',Fpbar=F)
>> sage: K81 = GF(81,'c',Fpbar=F)
>> sage: K81.has_coerce_map_from(K9)
>> True
>>
>
> Still speaking from a user's point of view, is there also a technical
> difficulty in keeping just one lattice of fields? So a new creation of a
> finite field gets automatically fitted into the canonical lattice?
>

You want to be able to create finite fields that don't fit into the
lattice, because as the degree increases it becomes very expensive to
compute polynomials that are compatible with the other extensions that
you've already constructed.  In contrast, constructing a finite field using
a random polynomial is relatively cheap.  Currently, Sage uses the presence
or absence of a specified variable name to determine whether you want a
field that fits into this lattice or not.

One application for having multiple lattices is to support algebraic
closures for non-prime fields (which is not yet implemented in Sage).
David

-- 
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: Finite fields coercion bug

[Kwankyu Lee]

Hi David,

First, thank you for technical explanations. They are compelling.

On Thursday, October 13, 2016 at 9:59:50 PM UTC+2, David Roe wrote:
>
>
> In order to create finite fields with arbitrary variable names that fit 
> into a lattice of fields, one possibility would be able to give an 
> algebraic closure explicitly as an argument to GF.  Is that what you're 
> suggesting?
> sage: F = GF(3).algebraic_closure('custom')
> sage: K9 = GF(9,'b',Fpbar=F)
> sage: K81 = GF(81,'c',Fpbar=F)
> sage: K81.has_coerce_map_from(K9)
> True
>

Still speaking from a user's point of view, is there also a technical 
difficulty in keeping just one lattice of fields? So a new creation of a 
finite field gets automatically fitted into the canonical lattice? 

-- 
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: Finite fields coercion bug

[David Roe]

On Thu, Oct 13, 2016 at 3:16 PM, John Cremona 
wrote:

> Thanks Peter for the explanation.  Nevertheless, I'm not sure that the
> normal user could have guess that one only gets the clever stuff
> (compatible embeddings into the algebraci closure.  The docstring GF?
> does imply this but again does not make a big thing of it.
>
> I think a better design (just of the user interface) would be to
> separate these two things: (i) whether or not you want the field being
> constructed to be part of the potentially costly lattice of fields,
> and (ii) whether or not you want to pick your own name.
>

In order to create finite fields with arbitrary variable names that fit
into a lattice of fields, one possibility would be able to give an
algebraic closure explicitly as an argument to GF.  Is that what you're
suggesting?
sage: F = GF(3).algebraic_closure('custom')
sage: K9 = GF(9,'b',Fpbar=F)
sage: K81 = GF(81,'c',Fpbar=F)
sage: K81.has_coerce_map_from(K9)
True

This would be pretty easy to implement (feel free to suggest a name for the
keyword other than 'Fpbar').


> Kwankyu's point is also a good one.  It really is not acceptable (from
> a user's point of view) to ask if there any coercions, be told there
> are none, and then be prevented from defining one!
>

This is much tougher, for technical reasons (I agree that it's not ideal
from a user's perspective).  Suppose that you're trying to determine
whether there's a coercion from A to B.  You know that there's a coercion
from C to B, so you check to see if there's a coercion from A to C,
discovering that there isn't.  After searching for a bit, you determine
that none of the ideas for constructing a coercion from A to C worked out,
so there isn't a coercion.  In order to forgo this search every time a
coercion from A to B is requested, you cache the result: there is no
coercion A to B and no coercion A to C.  These caches are stored on B and C.

Now suppose that the user wants to add a coercion from A to C.  If you
allowed this, then the coercion diagram becomes inconsistent, since this
coercion should have implied a coercion from A to B.  But there's no easy
way to update the cache on B, since it's not stored on A or C.  Sage's
solution is to not allow registering coercions A to B once it has used the
fact that there is no coercion.

Now, it's possible that one could restructure the system to make this
possible.  But it wouldn't be easy, and may involve other costs.  If you
have suggestions on how to update the documentation to make the issues
clearer, that's another matter.  :-)
David

>
> Meanwhile, now we know what is going on we can work round it (here we
> is me + my student Marco Caselli, who came to me saying that  it
> appeared to be impossible to iterate over a finite field if it was
> constructed as an extension of another -- which is true if you
> construct things in a perfectly innocent way without realising what is
> happening behind the scenes).
>
> John
>
> On 13 October 2016 at 18:25, Kwankyu Lee  wrote:
> > Hi,
> >
> > On Thursday, October 13, 2016 at 7:14:27 PM UTC+2, Peter Bruin wrote:
> >>
> >> Even though there is no coercion map in this situation, simply trying to
> >> discover a coercion "taints" the target parent by registering the fact
> >> that there is no coercion.
> >
> >
> > Then should we consider this behavior as a bug? There is a coercion rule
> > that there can be at most one coercion from a parent to another parent,
> but
> > it should not be disallowed to register one when there is none yet.
> Right?
> >
> > --
> > 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.
>
> --
> 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.
>

-- 
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: Finite fields coercion bug

[John Cremona]

Thanks Peter for the explanation.  Nevertheless, I'm not sure that the
normal user could have guess that one only gets the clever stuff
(compatible embeddings into the algebraci closure.  The docstring GF?
does imply this but again does not make a big thing of it.

I think a better design (just of the user interface) would be to
separate these two things: (i) whether or not you want the field being
constructed to be part of the potentially costly lattice of fields,
and (ii) whether or not you want to pick your own name.

Kwankyu's point is also a good one.  It really is not acceptable (from
a user's point of view) to ask if there any coercions, be told there
are none, and then be prevented from defining one!

Meanwhile, now we know what is going on we can work round it (here we
is me + my student Marco Caselli, who came to me saying that  it
appeared to be impossible to iterate over a finite field if it was
constructed as an extension of another -- which is true if you
construct things in a perfectly innocent way without realising what is
happening behind the scenes).

John

On 13 October 2016 at 18:25, Kwankyu Lee  wrote:
> Hi,
>
> On Thursday, October 13, 2016 at 7:14:27 PM UTC+2, Peter Bruin wrote:
>>
>> Even though there is no coercion map in this situation, simply trying to
>> discover a coercion "taints" the target parent by registering the fact
>> that there is no coercion.
>
>
> Then should we consider this behavior as a bug? There is a coercion rule
> that there can be at most one coercion from a parent to another parent, but
> it should not be disallowed to register one when there is none yet. Right?
>
> --
> 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.

-- 
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: Finite fields coercion bug

[Kwankyu Lee]

Hi,

On Thursday, October 13, 2016 at 7:14:27 PM UTC+2, Peter Bruin wrote:
>
> Even though there is no coercion map in this situation, simply trying to 
> discover a coercion "taints" the target parent by registering the fact 
> that there is no coercion.


Then should we consider this behavior as a bug? There is a coercion rule 
that there can be at most one coercion from a parent to another parent, but 
it should not be disallowed to register one when there is none yet. Right?

-- 
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: Finite fields coercion bug

[Peter Bruin]

Hello John,

> I think this is a bug.  In one Sage session:
>
> sage: F4 = GF(4)
> sage: F16 = GF(16)
> sage: F4.gen() in F16
> True
> sage: F16.has_coerce_map_from(F4)
> True
>
> -- all is well.  But in a new session:
>
> sage: F4 = GF(4, names='a')
> sage: F16 = GF(16, names='b')
> sage: F4.gen() in F16
> False
> sage: F16.has_coerce_map_from(F4)
> False
>
> Why should the fact that I have given non-default names to the
> generators (the default names are z2 and z4) stop the coercion being
> dicovered?

Creating finite fields without a variable name was implemented in
.  If you don't specify a
variable, then the field is created as a subfield of an algebraic
closure, and there are canonical inclusions between such fields.
Otherwise, the finite field does not have such a distinguished
embedding.

By the way, creating finite fields without a variable name is something
that you should only do for small fields, because constructing an
algebraic closure requires computing (pseudo-)Conway polynomials.

> Worse than that, I tried to create my own coercion from F4 to F16 in
> the second situation and it prevented me from doing so, saying there
> already was one, while at the same time telling me there was no
> coercion.  Inconsistent!

Even though there is no coercion map in this situation, simply trying to
discover a coercion "taints" the target parent by registering the fact
that there is no coercion.  It does work if you don't call
has_coerce_map() first:

sage: F4 = GF(4, names='a')
sage: F16 = GF(16, names='b')
sage: f = F4.Hom(F16)[0]
sage: F16.register_coercion(f)

You can't rely on this to work, though, because it can fail if F16 was
already created in this Sage session.

Peter

-- 
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] Finite fields coercion bug

[John Cremona]

I think this is a bug.  In one Sage session:

sage: F4 = GF(4)
sage: F16 = GF(16)
sage: F4.gen() in F16
True
sage: F16.has_coerce_map_from(F4)
True

-- all is well.  But in a new session:

sage: F4 = GF(4, names='a')
sage: F16 = GF(16, names='b')
sage: F4.gen() in F16
False
sage: F16.has_coerce_map_from(F4)
False

Why should the fact that I have given non-default names to the
generators (the default names are z2 and z4) stop the coercion being
dicovered?  Worse than that, I tried to create my own coercion from F4
to F16 in the second situation and it prevented me from doing so,
saying there already was one, while at the same time telling me there
was no coercion.  Inconsistent!

John

-- 
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: Make OpenBLAS Error

[Jeroen Demeyer]

On 2016-10-13 11:31, Sébastien Labbé wrote:

Is there a page in the Sage wiki or Sage documentation about "How to
install Sage from source faster" that gathers all those tricks?


This page is the best I can think of:
http://doc.sagemath.org/html/en/installation/source.html


For example, how do I know that the architecture of my dual core os x
laptop is|CoreDuo or |||Core2| or Corei2 or whatever when I want to set
the |||SAGE_ATLAS_ARCH?


Sage no longer compiles ATLAS by default.

--
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] About exceptions

[Jeroen Demeyer]

On 2016-10-13 10:56, Jori Mäntysalo wrote:

I opened https://trac.sagemath.org/ticket/2169 to make some example.

I guess you mean that for example

ValueError("%s and %s must be positive integers." % (m, n))

should be as it is, but

ValueError("the poset is not ranked")

changed to ArithmeticError.


Something like this, yes. Although we all seem to agree that this is 
mostly bikeshedding.


--
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: Make OpenBLAS Error

[Sébastien Labbé]

Is there a page in the Sage wiki or Sage documentation about "How to 
install Sage from source faster" that gathers all those tricks?

The only thing I currently use is parallel stuff : export MAKE = "make -j4"

For example, how do I know that the architecture of my dual core os x 
laptop is CoreDuo or Core2 or Corei2 or whatever when I want to set the 
SAGE_ATLAS_ARCH?

http://doc.sagemath.org/html/en/installation/source.html#environment-variables

On Thursday, October 13, 2016 at 11:03:20 AM UTC+2, François wrote:
>
> Not spending the time compiling gcc to get gfortran? 
>
> François 
>
> > On 13/10/2016, at 22:01, Sébastien Labbé  
> wrote: 
> > 
> > 
> > 
> > On Wednesday, October 12, 2016 at 9:07:24 PM UTC+2, Eric Gourgoulhon 
> wrote: 
> > > with Ubuntu 16.04, if you install the Ubuntu package gfortran-5, your 
> Sage build will use the system gfortran, which works fine (no missing 
> libgfortran.so.3). 
> > 
> > Is there any other reason/advantage for Sage to use the system gfortran? 
> > 
> > Sébastien 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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: Make OpenBLAS Error

[Francois Bissey]

Not spending the time compiling gcc to get gfortran?

François

> On 13/10/2016, at 22:01, Sébastien Labbé  wrote:
> 
> 
> 
> On Wednesday, October 12, 2016 at 9:07:24 PM UTC+2, Eric Gourgoulhon wrote:
> > with Ubuntu 16.04, if you install the Ubuntu package gfortran-5, your Sage 
> > build will use the system gfortran, which works fine (no missing 
> > libgfortran.so.3). 
> 
> Is there any other reason/advantage for Sage to use the system gfortran?
> 
> Sébastien
> 
> -- 
> 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.

-- 
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: Make OpenBLAS Error

[Sébastien Labbé]

On Wednesday, October 12, 2016 at 9:07:24 PM UTC+2, Eric Gourgoulhon wrote:
> with Ubuntu 16.04, if you install the Ubuntu package gfortran-5, your 
Sage build will use the system gfortran, which works fine (no missing 
libgfortran.so.3). 

Is there any other reason/advantage for Sage to use the system gfortran?

Sébastien

-- 
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] About exceptions

[Jori Mäntysalo]

I opened https://trac.sagemath.org/ticket/2169 to make some example.

I guess you mean that for example

ValueError("%s and %s must be positive integers." % (m, n))

should be as it is, but

ValueError("the poset is not ranked")

changed to ArithmeticError.

--
Jori Mäntysalo

Re: [sage-devel] About exceptions

[Daniel Krenn]

On 2016-10-13 08:11, Jeroen Demeyer wrote:
> On 2016-10-12 13:39, Jori Mäntysalo wrote:
>>  elements = D.topological_sort()
> 
> More bikeshedding: in this case, I would even consider ArithmeticError.
> It's not strictly arithmetic, but it does indicate a mathematical issue.
> I tend to use ArithmeticError for mathematical errors (something doesn't
> work because it is mathematically not defined)

+1

-- 
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] About exceptions

[Daniel Krenn]

On 2016-10-12 16:01, Daniel Krenn wrote:
> On 2016-10-12 13:39, Jori Mäntysalo wrote:
> There could be a ContainsCycleError which has RuntimeError as a base...

As mentioned in another part of this thread: ...ArithmethicError as a
base...


-- 
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] Giving Sage AI-based step-by-step equation solving abilities

[Johan S . H . Rosenkilde]

Hi Ted,

As William stated, I think any functionality improving SageMath's appeal
for, say, educating high school students would be very welcome. My main
concern is how valuable what you propose with PRESS-like printing is in
this respect.

You gave a printout of your current PRESS implementation earlier, for
solving a simple linear equation in one variable. That printout is
extremely verbose and very micro-syntactically oriented. My guess would
be that few high school teachers would wish to teach the simple isolation of a
variable technique that way. And students struggling with the technique
would mostly just become more confused ("undefine the binary '-' operator",
"change the association of +", etc.), and would fail building up
mathematical intuition but rather focus on the syntax.

You gave the following examples of more advanced problems PRESS can
solve:

> 4^(2*x+1) * 5^(x-2) = 6^(1-x)  (A.E.B. November 1971)
> cos(x) + cos(3*x) + cos(5*x) = 0  (A.E.B. June 1976)
> 3*tan(3*x) - tan(x) + 2 = 0  (Oxford Autumn 1978)
> log_2 x + 4*log_x 2 = 5  (London January 1978)
> 3*sech^2(x) + 4*tanh(x) + 1 = 0  (A.E.B. June 1971)
> log_e(x+1) + log_e(x-1) = 3
> e^(3*x) - 4*e^x + 3*e^(-x) = 0  (London June 1977)
> cosh(x) - 3*sinh(y) = O & 2*sinh(x) + 6*cosh(y) = 5  (A.E.B. June 1973)"

In Denmark - and my impression is that the same goes for other countries
as well - high school curriculum has largely moved away from solving of
such equations using identities and "tricks". The cos(x+y) identities
etc. and similar are not even taught anymore. In algebra, students
mostly solve linear equations with 1 or 2 unknowns and second-degree
equations. Simple isolation involving logs and exponentials, and there's
also some simplification and/or factoring of e.g. polynomial fractions
involved in function analysis.

Best,
Johan

-- 
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] About exceptions

[Jori Mäntysalo]

On Thu, 13 Oct 2016, Jeroen Demeyer wrote:


So we have now a common view that 'type' in TypeError should (mostly?)
refer to types in wrong class, wrong category etc


For Sage, I would certainly add "wrong parent" to this.


True. And there might be some, eh, exceptions to this rule. But mostly 
.is_something() should not raise TypeError and sentences like "The poset 
is expected to be bounded." in docstring should mean that non-bounded 
poset will not raise TypeError.


Python also uses TypeError to indicate a function which is called with 
the wrong number of arguments or bad keyword arguments:



str(foo=1)

Traceback (most recent call last):
 File "", line 1, in 
TypeError: 'foo' is an invalid keyword argument for this function


I didn't notice that. I would have expected more exact exception for 
those.



 elements = D.topological_sort()


More bikeshedding: in this case, I would even consider ArithmeticError. It's 
not strictly arithmetic, but it does indicate a mathematical issue. I tend to 
use ArithmeticError for mathematical errors (something doesn't work because 
it is mathematically not defined) and ValueError for programming errors (an 
input which a priori does not make sense).


Documentation for ValueError says "- - and the situation is not described 
by a more precise exception - -". Maybe there should be something like 
MathematicalError as a base class instead of ArithmeticError, but we can't 
change that.


--
Jori Mäntysalo

Re: [sage-devel] Make OpenBLAS Error

[Jeroen Demeyer]

On 2016-10-12 18:14, Ethan Petersen wrote:

there was an "Error building OpenBLAS"/"Error installing package 
openblas-0.2.19" with a suggestion to email this google group with the attached log file.


I'm glad that you did that! Almost *nobody* seems to read that message.


If anyone has ideas on solving this issue, please let me know!


There is a fix at https://trac.sagemath.org/ticket/21689 but it's not 
yet in a Sage release.


--
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] About exceptions

[Jeroen Demeyer]

On 2016-10-12 13:39, Jori Mäntysalo wrote:

 elements = D.topological_sort()


More bikeshedding: in this case, I would even consider ArithmeticError. 
It's not strictly arithmetic, but it does indicate a mathematical issue. 
I tend to use ArithmeticError for mathematical errors (something doesn't 
work because it is mathematically not defined) and ValueError for 
programming errors (an input which a priori does not make sense).


--
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] About exceptions

[Jeroen Demeyer]

On 2016-10-12 18:56, Jori Mäntysalo wrote:

So we have now a common view that 'type' in TypeError should (mostly?)
refer to types in wrong class, wrong category etc


For Sage, I would certainly add "wrong parent" to this.

Python also uses TypeError to indicate a function which is called with 
the wrong number of arguments or bad keyword arguments:


>>> str(foo=1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'foo' is an invalid keyword argument for this function

--
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.