Re: [sage-devel] Re: Coercion between quadratic fields fails (by default)

[Nils Bruin]

On Saturday, November 30, 2019 at 5:10:48 PM UTC-8, vdelecroix wrote:
>
>
> Calling c.minpoly() triggers some exactification. Compare with 
>
> sage: a = AA(2).sqrt() 
> sage: b = AA(3).sqrt() 
> sage: (a + b) * (a - b) * (b - a) * (-a -b) 
> 1.000? 
>
Sure, but there is no "numerical noise" other than in the internal interval 
arithmetic and perhaps a little strange printing. In all cases, the 
quantity computed is exactly 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/99e2c4eb-d38e-4b2b-b5f7-10dc2340bcc9%40googlegroups.com.

Re: [sage-devel] Re: Coercion between quadratic fields fails (by default)

[Vincent Delecroix]

Le 30/11/2019 à 14:52, Nils Bruin a écrit :



On Saturday, November 30, 2019 at 1:47:47 PM UTC-8, Jonathan Kliem wrote:



I don't know if the choice of RLF was appropriate for a default embedding,

but I'd be wary of embedding in AA/QQbar by default, because they are so
unpredictable in their performance. Generally, you should NOT be computing
in them except for exploratory work. It's usually possible to be more
specific about the desired field with a bit of analysis and then you'll get
much better and reliable performance.



So is the current setup is meant to tell the user to think and figure out
a good conversion him/herself?



That's how I interpret it, yes, and from experience, one should probably
think of getting a good representation of the relevant field for one's
purposes, since I don't think there is a universally good choice.
  


I mean there is composite field and one can always convert to that and
work there.



Indeed, and I think for most algebraic purposes that will perform best.
  



Still conversion to AA and QQbar should work without numerical noise. But
that is a different topic.

And I think they do. Those fields use an algebraic representation,

together with interval arithmetic. So things might print with numerical
noise but that's just an artifact of using the interval arithmetic
representation.
Magma, for instance, uses an implementation of QQbar that is backed by
finite field arithmetic instead of interval arithmetic. That is probably
cheaper and more predictable performance-wise in most cases, but carries
the low-probability event of a characteristic-based disaster, where it
turns out the residue characteristic prime shows up in a numerator or a
denominator.
  
There's no numerical noise as far as I can see:


sage: A.=QuadraticField(2,embedding=AA(2).sqrt())
sage: B.=QuadraticField(3,embedding=AA(3).sqrt())
sage: c=a+b; c #this is just how it prints
3.146264369941973?
sage: c.minpoly()
x^4 - 10*x^2 + 1
sage: (a+b)*(a-b)*(b-a)*(-a-b)
1



Calling c.minpoly() triggers some exactification. Compare with

sage: a = AA(2).sqrt()
sage: b = AA(3).sqrt()
sage: (a + b) * (a - b) * (b - a) * (-a -b)
1.000?

--
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/caa763b2-e158-7288-29f6-a7407471e862%40gmail.com.

Re: [sage-devel] Request for comments: add a "domain=" option to symbolic integration methods/functions

[Emmanuel Charpentier]

Le dimanche 1 décembre 2019 00:16:24 UTC+1, Thierry (sage-googlesucks@xxx) 
a écrit :
>
> Hi, 
>
> On Fri, Nov 29, 2019 at 04:41:20PM -0800, rjf wrote: 
> > I mentioned in answer to another thread about Maxima/domain/integration 
> > the caution that this is likely missing the point. 
> > Setting a domain or passing this setting to Maxima is not a solution. 
> > It is likely a symptom that you are making a mathematical error. 
> > 
> > quoting in part.. 
> > 
> > Since log() is in general multivalued, any answer that 
> > ignores this possibility may fall into a trap.  Setting a domain 
> > to something or other does not necessarily avoid the trap. 
> > An example that is simpler and perhaps reminiscent of this 
> > kind of error is to assert that   sqrt(x^2) is x  or abs(x), when 
> > YOU KNOW there are UNDENIABLY (except if x=0)  TWO square roots,  x, -x. 
> > Even if you know that x is positive,  there are still two 
> > square roots. sqrt(9) has 2 values. 
> > 
> >   Unless you want 
> > to define sqrt as something else. .. 
> > 
> >  end quote.. 
> > 
> > Maybe as another illustration of how blunt an instrument is 
> > the "domain" declaration, consider  that you have computed 
> > a value for s, which is supposed to be 1, but because of a 
> > numerical roundoff, comes out as 0.9... 
> > computing z :=sqrt(s-1), which should be 0, turns out to be 
> > complex.   What do you really want to do?   Are you OK 
> > with computing w:= z-z  which is real, but whose computation 
> > wandered very slightly into the complex domain? 
> > 
> > 
> > The use of declarations for integration results is probably 
> > an attempt to react to naivety or stubbornness based 
> > on "if my freshman calculus teacher said XXX and you 
> > said YYY  then you are wrong".  Leading to (for example) 
> > spewing out log (abs(...))  instead of log(...), and other 
> mathematically 
> > logically subtle errors caused by the complaint,  "But I haven't learned 
> > about 
> > sqrt(-1) so that can't occur in the answer to any questions 
> > that I ask." 
> > 
> > Perspective:  you can diddle with trying to set domains 
> > "right" but you have probably missed the boat in the 
> > system design and are unlikely to be able to patch it. 
> > This issue was sort of understood in, roughly, 1974 
> > by the people working on Macsyma, who figured there 
> > was not the time or money and maybe not the smarts 
> > to do a new design.  Mostly subsequently, other systems 
> > were built that more-or-less duplicated the design that 
> > we thought was not going to work.  It is possible, even likely, to 
> > design a system that works just fine for algebra, but 
> > doesn't work for complex analysis.  (just look up the 
> > grad course in your college catalog and see if you can 
> > do the homework problems using Sage.) 
>
> In case someone would like to give a try, could you please provide some 
> details of what would have been a good design ? 
>

I am afraid that what rjf points to is that we should redesign calculus (or 
even analysis...). and the worst is that he may be right:

The counterexample pointed in the ticket is that (long story short) 
log(-x)==log(x*-1))==log(x)+log(-1)==log(x) + some integration constant, 
which might well be log(i*pi). This is horribly contrerintuitive, but makes 
sense  in our (at leas my) understanding of the calculus.

Which may well mean that this understanding has to be corrected. But we're 
no longer talking software, but mathematics... *way* over my pay grade !
 

>
> Ciao, 
> Thierry 
>
>
> > Sorry for being such a pessimist, but some of us have 
> > been there. 
> > 
> > Regards 
> > 
> > RJF 
> > 
> > 
> > On Friday, November 29, 2019 at 3:46:59 PM UTC-8, Michael Orlitzky 
> wrote: 
> > > 
> > > On 11/29/19 2:01 PM, Emmanuel Charpentier wrote: 
> > > > Dear list, 
> > > > 
> > > > We have a non inconsiderable stock of tickets whose analysis ends up 
> > > > with someting amounting to "bug due the domain:complex option in 
> > > > Maxima", and no solution in view. 
> > > 
> > > Which tickets? Are they all integration? 
> > > 
> > > 
> > > > Couldn't we work around this problem by offering a "domain=" option 
> > > > (default value =complex") which, when set, would wrap the call to 
> > > > Maxima's library in a pair of Maxima statements setting 
> (temporarily) 
> > > > "domain:real" ? A "try: ... except: ... finally:..." statement would 
> > > > probably be the right way to do it. 
> > > > 
> > > 
> > > I added Expression.simplify_real() to do this during simplification, 
> so 
> > > the sketchy domain-twiddling code is there for the taking. 
> > > 
> > 
> > -- 
> > 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 
> 

Re: [sage-devel] Request for comments: add a "domain=" option to symbolic integration methods/functions

[Thierry]

Hi,

On Fri, Nov 29, 2019 at 04:41:20PM -0800, rjf wrote:
> I mentioned in answer to another thread about Maxima/domain/integration
> the caution that this is likely missing the point.
> Setting a domain or passing this setting to Maxima is not a solution.
> It is likely a symptom that you are making a mathematical error.
> 
> quoting in part..
> 
> Since log() is in general multivalued, any answer that
> ignores this possibility may fall into a trap.  Setting a domain
> to something or other does not necessarily avoid the trap.
> An example that is simpler and perhaps reminiscent of this
> kind of error is to assert that   sqrt(x^2) is x  or abs(x), when
> YOU KNOW there are UNDENIABLY (except if x=0)  TWO square roots,  x, -x.
> Even if you know that x is positive,  there are still two
> square roots. sqrt(9) has 2 values.
> 
>   Unless you want
> to define sqrt as something else. ..
> 
>  end quote..
> 
> Maybe as another illustration of how blunt an instrument is
> the "domain" declaration, consider  that you have computed
> a value for s, which is supposed to be 1, but because of a
> numerical roundoff, comes out as 0.9...
> computing z :=sqrt(s-1), which should be 0, turns out to be
> complex.   What do you really want to do?   Are you OK
> with computing w:= z-z  which is real, but whose computation
> wandered very slightly into the complex domain?
> 
> 
> The use of declarations for integration results is probably
> an attempt to react to naivety or stubbornness based
> on "if my freshman calculus teacher said XXX and you
> said YYY  then you are wrong".  Leading to (for example)
> spewing out log (abs(...))  instead of log(...), and other mathematically
> logically subtle errors caused by the complaint,  "But I haven't learned 
> about
> sqrt(-1) so that can't occur in the answer to any questions
> that I ask."
> 
> Perspective:  you can diddle with trying to set domains
> "right" but you have probably missed the boat in the
> system design and are unlikely to be able to patch it.
> This issue was sort of understood in, roughly, 1974
> by the people working on Macsyma, who figured there
> was not the time or money and maybe not the smarts
> to do a new design.  Mostly subsequently, other systems
> were built that more-or-less duplicated the design that
> we thought was not going to work.  It is possible, even likely, to
> design a system that works just fine for algebra, but
> doesn't work for complex analysis.  (just look up the
> grad course in your college catalog and see if you can
> do the homework problems using Sage.)

In case someone would like to give a try, could you please provide some
details of what would have been a good design ?

Ciao,
Thierry


> Sorry for being such a pessimist, but some of us have
> been there.
> 
> Regards
> 
> RJF
> 
> 
> On Friday, November 29, 2019 at 3:46:59 PM UTC-8, Michael Orlitzky wrote:
> >
> > On 11/29/19 2:01 PM, Emmanuel Charpentier wrote: 
> > > Dear list, 
> > > 
> > > We have a non inconsiderable stock of tickets whose analysis ends up 
> > > with someting amounting to "bug due the domain:complex option in 
> > > Maxima", and no solution in view. 
> >
> > Which tickets? Are they all integration? 
> >
> >
> > > Couldn't we work around this problem by offering a "domain=" option 
> > > (default value =complex") which, when set, would wrap the call to 
> > > Maxima's library in a pair of Maxima statements setting (temporarily) 
> > > "domain:real" ? A "try: ... except: ... finally:..." statement would 
> > > probably be the right way to do it. 
> > > 
> >
> > I added Expression.simplify_real() to do this during simplification, so 
> > the sketchy domain-twiddling code is there for the taking. 
> >
> 
> -- 
> 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/ffe89d32-d461-44ee-8e86-03b8c0efa5a1%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/20191130231620.ahk7vxkjvth2wfly%40metelu.net.

[sage-devel] Re: Coercion between quadratic fields fails (by default)

[Nils Bruin]

On Saturday, November 30, 2019 at 1:47:47 PM UTC-8, Jonathan Kliem wrote:
>
>
> I don't know if the choice of RLF was appropriate for a default embedding, 
>> but I'd be wary of embedding in AA/QQbar by default, because they are so 
>> unpredictable in their performance. Generally, you should NOT be computing 
>> in them except for exploratory work. It's usually possible to be more 
>> specific about the desired field with a bit of analysis and then you'll get 
>> much better and reliable performance.
>>
>
> So is the current setup is meant to tell the user to think and figure out 
> a good conversion him/herself?
>

That's how I interpret it, yes, and from experience, one should probably 
think of getting a good representation of the relevant field for one's 
purposes, since I don't think there is a universally good choice.
 

> I mean there is composite field and one can always convert to that and 
> work there.
>

Indeed, and I think for most algebraic purposes that will perform best.
 

>
> Still conversion to AA and QQbar should work without numerical noise. But 
> that is a different topic.
>
> And I think they do. Those fields use an algebraic representation, 
together with interval arithmetic. So things might print with numerical 
noise but that's just an artifact of using the interval arithmetic 
representation.
Magma, for instance, uses an implementation of QQbar that is backed by 
finite field arithmetic instead of interval arithmetic. That is probably 
cheaper and more predictable performance-wise in most cases, but carries 
the low-probability event of a characteristic-based disaster, where it 
turns out the residue characteristic prime shows up in a numerator or a 
denominator.
 
There's no numerical noise as far as I can see:

sage: A.=QuadraticField(2,embedding=AA(2).sqrt())
sage: B.=QuadraticField(3,embedding=AA(3).sqrt())
sage: c=a+b; c #this is just how it prints
3.146264369941973?
sage: c.minpoly()
x^4 - 10*x^2 + 1
sage: (a+b)*(a-b)*(b-a)*(-a-b)
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b590aef8-87c6-4c00-b898-e1b5dc40cc6f%40googlegroups.com.

[sage-devel] Re: Coercion between quadratic fields fails (by default)

['Jonathan Kliem' via sage-devel]

Thanks for the comment.

Am Freitag, 29. November 2019 22:47:13 UTC+1 schrieb Nils Bruin:
>
>
>
> On Friday, November 29, 2019 at 12:45:45 PM UTC-8, Jonathan Kliem wrote:
>>
>> The following leads to a TypeError:
>>
>> sage: K2. = QuadraticField(2)
>> sage: K3. = QuadraticField(3)
>> sage: sqrt2 + sqrt3
>>
>> Both of them are real embedded by default, so coercion should work (at least 
>> this is my opinion).
>>
>> This can be fixed by specifying that both of them are embedded into the 
>> algebraic reals (at the moment RLF is default).
>>
>>
> Embedding into RLF is really meant to be "embedding into real floats, with 
> yet-to-be-specified precision". Float arithmetic has very different 
> properties from AA/QQbar: it's reliably quick, but imprecise and with no 
> equality test., whereas AA/QQbar is unpredictable in computation speed and 
> possibly VERY expensive (but reliable) equality test. 
>

> I don't know if the choice of RLF was appropriate for a default embedding, 
> but I'd be wary of embedding in AA/QQbar by default, because they are so 
> unpredictable in their performance. Generally, you should NOT be computing 
> in them except for exploratory work. It's usually possible to be more 
> specific about the desired field with a bit of analysis and then you'll get 
> much better and reliable performance.
>

So is the current setup is meant to tell the user to think and figure out a 
good conversion him/herself?

I mean there is composite field and one can always convert to that and work 
there. Or convert to the reals, if one looks for a numerical solution.

Still conversion to AA and QQbar should work without numerical noise. But 
that is a different topic.


> Also casting sqrt2 to AA does not work at the moment (at least not without 
> numerical noise).
>>
>> Is it reasonable to apply this by default (i.e. embed quadratic fields into 
>> AA/QQbar)?
>> This would lead to failing doctests for mostly two reasons:
>>
>>
>>- numerical approximation works differently for AA and RLF
>>- cyclotomic should be standard embedded into QQbar then
>>
>> Are there specific reasons, that they are embedded into RLF resp. CLF at 
>> the moment?
>>
>> I opened a 28774  for this.
>>
>> My motivation: It seems very natural to construct a polyhedron over 
>> quadratic fields. However, coercion of those polyhedra does not work. See 
>> 28776 
>>
>

-- 
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/929277c9-c038-424b-b456-0d788b4db853%40googlegroups.com.

[sage-devel] Re: Request for comments: Padé approximants

[Vincent Neiger]

Concerning what minimal_approximant_basis returns: this is specified in the 
documentation, 
http://doc.sagemath.org/html/en/reference/matrices/sage/matrix/matrix_polynomial_dense.html#sage.matrix.matrix_polynomial_dense.Matrix_polynomial_dense.minimal_approximant_basis
but in formal (hence technical) terms. Let me try to give a more 
"intuitive" description of the terms in the documentation.

*Basis of the module of approximants:*
In your case, the space of all solutions to the Padé equation (ignoring 
degree constraints) is something of dimension 2, which is generated by 2 
elements (each of them being a pair of univariate polynomials).
The algorithm returns a basis of that space, represented as a 2 x 2 matrix: 
the space of all solutions to the Pade equation is precisely the set of 
linear combinations (with polynomial coefficients) of the two rows of the 
matrix.

*Basis in shifts-ordered weak Popov form:*
The algorithm does not return any basis; it returns one which has specific 
degree properties (setting the input parameter normal_form to True further 
reduces the entries to obtain a uniquely defined basis).
By setting the shift to the negated degree constraints, these degree 
properties ensure in particular that one of the two rows will satisfy the 
Padé degree constraints (assuming these were chosen so that there is a 
solution). If the degree constraints were chosen tight (their sum is the 
precision), the other row will not satisfy the degree constraints, so in 
this case the choice is easy: take the row which satisfies the constraints.

Hoping this clarifies a bit what the output looks like.

Concerning speed, for which kind of base field did you make your 
experiments? In any case, this algorithm is much slower than the best 
existing ones (the complexity quadratic in the precision instead of 
quasi-linear). For the general Hermite-Pade problem handled by this 
algorithm, experiments showed that the faster ones were not that 
interesting in Sage for the moment: we would need a faster polynomial 
matrix multiplication. However, for this specific Padé case the matrices 
are 2 x 2, so it seems to me that here these faster algorithms could be 
indeed much faster (again I have "base field = finite field" in mind). I 
will look into this and keep you informed on this thread.


Le vendredi 29 novembre 2019 20:32:47 UTC+1, Emmanuel Charpentier a écrit :
>
> A big thank you for your help, which was absolutely necessary. Synthesis:
>
> 1) Vincent Neiger's proposal works ; I have been able to obtain acceptable 
> duplications of Maxima's pade results in a small sample of test cases 
> (mostly by treating the "shifts" symmetrically).
>
> However, the overall combination of Sage's series and 
> minimal_approximant_basis, with the necessary base ring changes, seems a 
> tad slower than a straight translation to Maxima, chaining Maxima's taylor 
> and pade function and converting back to Sage.
>
> Furthermore, I think that this method is more general and may have other 
> applications ; the problem is that I do not (yet) understand what it does. 
> For example, it returns two rational fractions, whose "best" is not always 
> obvious to my naked eye...
>
> I will stock it for further exploration and separate implementation 
> (possibly more general than SR rational approximations).
>
> 2) I think that the "naïve" method of handling multiple variables is the 
> only one that can be used without supplementary information (and much more 
> understanding of the subject than I have currently).
>
> Therefore, unless I receive further advice or comments, a ticket (to be 
> announced) will propose a wrapper around Maxima's implementations, 
> "naïvely" extended to the multivariate case, with an extension of the 
> current argument passing of  taylor.
>
> Do you think that a paragraph should be added in the relevant 
> introduction/tutorial, texts (if so which ones ?) In this case, I think 
> that a word of caution about the limitations and pitfalls of this approach 
> to approximation should be part of it (e. g. the introductin of "spurious" 
> poles and zeroes, radiius of convergence, etc...). Again, advice welcome...
>
> Le dimanche 10 novembre 2019 14:32:52 UTC+1, Emmanuel Charpentier a écrit :
>>
>> Dear list,
>>
>> IMHO, Sage may use an implementation of Padé approximants (similar t its 
>> implementation of Taylor series), if only for numerical use reasons. 
>> Currently, this can be done:
>>
>>- by wrapping the Maxima functions taylor and pade (Maxima's pade 
>>needs a Maxima taylor development object, which does not cleanly 
>>translate to Sage);
>>- by using the PowerSeriesRing.pade method.
>>
>> Some trials have shown that the latter method, as advertised in its 
>> documentation, is indeed unsuitable even for moderately large degrees of 
>> the numerator and denominator: the expression thus obtained are extremely 
>> unwieldy large and are slow to evaluate numerically.
>> In contrast, the