9 views

Skip to first unread message

Sep 7, 2010, 5:26:39 PM9/7/10

to sage-s...@googlegroups.com, pynac...@googlegroups.com

Hi,

Here is a short example to replicate the first error mentioned below:

b = [var('b_%s'%i) for i in range(4)]

precomp = (2^b_2 + 2)*(2^b_1 + 2^(-b_1) + 2^b_1*2^b_0 - 2^b_1*2^(-b_0)

- 2^(-b_1)*2^b_0 - 2^(-b_1)*2^(-b_0) + 2^b_0 + 2^(-b_0) - 9) + (2^b_1 +

2^(-b_1) + 2^b_1*2^b_0 - 2^b_1*2^(-b_0) - 2^(-b_1)*2^b_0 -

2^(-b_1)*2^(-b_0) + 2^b_0 + 2^(-b_0) - 9)/2^b_2

repl_dict = {b_0: b_0, b_3: b_1, b_2: b_3, b_1: b_2}

P = precomp.substitute(repl_dict)

P.expand()

I will take a break now. I'd appreciate any help tracking down the

problem (in pynac) if anybody has the time.

Cheers,

Burcin

On Wed, 1 Sep 2010 08:25:07 -0700 (PDT)

Jean-Pierre Flori <jpf...@gmail.com> wrote:

> Hello,

>

> I'm using Sage to do some symbolic computations.

> What I am basically trying to do is to compute sums made of terms of

> the form :

> cst_{i_0,...,i_d)*b_0^{i_0}*...*b_d^{i_d}*2^{-b_0-...-b_d}

> where the b_i are variables

> (i.e. a product of an exponential with b_i in the exponent by a

> multivariate polynomial in b_i)

> using functions (especially symbolic_sum) from sage.calculus.calculus.

> I am regularly calling expand() and simplify() functions as well as

> some custom functions using substitute() to get a more compact

> expression and avoid redundant terms.

> Everything works fine as long as the sums are not too "complicated",

> but Sage segfaults when they become too big.

> Running Sage with the -gdb flag, gives different errors according to

> which of my functions I am calling, but both errors seem to be related

> to a "compare" function in Pynac (SIGSEGV or SIGBUS):

>

> First error message :

> Program received signal SIGSEGV, Segmentation fault.

> GiNaC::power::compare (this=0x3281c20, other=...) at power.cpp:899

> 899 power.cpp: Aucun fichier ou dossier de ce type.

> in power.cpp

>

> Second error message :

> Program received signal SIGBUS, Bus error.

> GiNaC::mul::compare (this=0x83490e0, other=...) at mul.cpp:1174

> 1174 mul.cpp: Aucun fichier ou dossier de ce type.

> in mul.cpp

>

>

> My box is running a Debian unstable with packages from the

> experimental repository.

> My kernel version is 2.6.35, compiled by myself.

> My cpu is a Intel(R) Core(TM)2 Quad CPU Q6600.

> The error is happening with Sage 4.5.2 and 4.4.4.

> I compiled both of them myself with gcc (Debian 4.4.4-11) 4.4.5

> 20100824 (prerelease).

> I also tried the precompiled sage-4.5.2-linux-64bit-ubuntu_10.04_lts-

> x86_64-Linux which gives me the same result.

>

> I didn't manage to reproduce the bug with a short and simple piece of

> code.

> However I can mail the source code and instructions to reproduce the

> bug to anyone who can help.

> I will also provide any information needed to investigate this

> problem.

> I am currently trying to compile Sage on another box to do another

> test.

> Any help will be appreciated, and thanks for a such a great piece of

> software.

>

> Best regards,

>

> Jean-Pierre Flori

>

Sep 12, 2010, 9:40:29 AM9/12/10

to sage-s...@googlegroups.com, pynac...@googlegroups.com

Hi Jean-Pierre,

On Thu, 9 Sep 2010 02:13:27 -0700 (PDT)

Jean-Pierre Flori <jpf...@gmail.com> wrote:

> I created a Ticket on Sage's Trac:

> http://trac.sagemath.org/sage_trac/ticket/9880

>

> It could be a problem with the comparison function

> "expair_rest_is_less" used by "std::sort" function like in the

> following link:

> http://gcc.gnu.org/ml/gcc-bugs/2010-08/msg01163.html

This is indeed the problem. Thanks for tracking it down.

In the process of adapting GiNaC for use in Sage, I changed the

comparison functions to give a consistent order between different runs.

Apparently, the new comparison functions I wrote are not consistent.

For a long time, I wanted to rip out these new functions, and use them

only for printing. The following patch is a first step towards this:

http://sage.math.washington.edu/home/burcin/pynac/pynac_order.patch

After applying this patch to pynac (see here [1] for instructions on

how to set up a pynac development environment), the segfault you

reported, and the bug at #9046 goes away.

Note that this is very much a work in progress. I didn't take care to

make sure these comparison functions are consistent either. In the

process of copying things over, I even flipped a few signs in the

results.

This needs much work to be finished, we need to make sure the order

is consistent and correct, and it matches the one currently used by

Sage. The issue of accessing the operands of a symbolic expression also

needs to be sorted out, but that's merely a user interface issue.

I'd appreciate help with any of this, since I don't have much time to

spend on Sage/pynac these days. I'd be glad to answer any questions

though.

Cheers,

Burcin

Sep 12, 2010, 12:36:26 PM9/12/10

to sage-s...@googlegroups.com, pynac...@googlegroups.com

Hi,

On Sun, 12 Sep 2010 09:21:12 -0700 (PDT)

Jean-Pierre Flori <jpf...@gmail.com> wrote:

> Thanks for the patch, I'll have a look at the comparison functions

> when I have some time, surely next week.

> Where can I find the one defined by Sage ?

They are spread out through the classes in pynac. Look for compare()

and compare_same_type() functions in mul, power, function, etc.

> I have another question: are the source codes of GiNaC and pynac still

> "synchronized" in some way ?

Not really. I pull some patches from GiNaC when I think they are

relevant.

> I saw that some recent changes are similar in both git repositories,

> but as I was going through the source code, I saw that

> numeric::do_print_csrc is defined in GiNaC but not in pynac.

The numeric class in pynac is completely rewritten to use python

objects instead of CLN. It's normal that those methods are missing.

Cheers,

Burcin

Sep 29, 2010, 2:28:14 PM9/29/10

to sage-s...@googlegroups.com, pynac...@googlegroups.com

On Wed, 29 Sep 2010 09:48:25 -0700 (PDT)

Jean-Pierre Flori <jpf...@gmail.com> wrote:

Jean-Pierre Flori <jpf...@gmail.com> wrote:

> Maybe it is a good thing to keep the same order as ginac internally

> and your more usual ordering for printing.

It is good to keep the ginac ordering internally. The user friendly

ordering is more expensive so it slows down computations, even when

you don't print intermediate expressions.

> However if you'd better not duplicate code, I can look at the "-

> x^2+x^2" part of bug #9046.

> Now I may understand a big enough part of pynac code to do that.

That's right. You're one of the few people who spent so much time

staring at pynac code. :)

> But if you'd better use the above patch, that won't be necessary.

I would like to replace the orders completely. I wanted to attack

this problem for a long time. Now that we started, we might as

well finish. :)

Can you help put the patch in usable shape? At the moment the ordering

it defines is completely different from the one we use in Sage. This

must be because I changed some signs while I was copying code.

If you can make the ordering consistent, I can fix the other relevant

places (op(), etc.).

Thanks.

Burcin

Oct 1, 2010, 2:59:46 PM10/1/10

to Jean-Pierre Flori, pynac...@googlegroups.com

Hi,

This discussion should really be on pynac-devel. I set the Reply-To

address accordingly. I hope it works. ;)

On Fri, 1 Oct 2010 06:52:11 -0700 (PDT)

Jean-Pierre Flori <jpf...@gmail.com> wrote:

> Some remarks and questions...

>

> I guess the order you want is 'degrevlex' as Sage's default order for

> multivariate polynomial ring and as the name of your functions

> suggest.

> Am I wrong ?

You are right, some approximation of 'degrevlex'.

> At present, I did not modify a lot of things.

> A few signs, replaced seq[0] by the smallest item of the sequence

> sorted with the printing order.

Nice. I totally forgot about having to sort subexpressions.

> I guess we want symbolic variables to be bigger than numerics.

> So I changed the sign for different typeid's.

OK.

> What is your opinion about symbolic exponents ?

> (If I am not wrong, in mul object, they are encapsulated in power

> object so it counts for 1.

> So total_degree(a^b*x) == 2.)

> In the compare_mul_power, you decided to compare the exponent of the

> power object to the one of the smallest item (which could in fact be

> the same power object) of the mul object if it is symbolic.

> So 3*x^y will be smaller than x^y (considering that y > 1).

> That is not a "real" problem because 3*x^y+x^y will be simplified into

> 4*x^y.

> But we also get that a^b > a^b*x (if b > 1) with the current strategy

> and it prints a^b + a^b*x...

It looks like you just need to return a^b < a^b*x. This is also what we

have now:

sage: var('a,b,x')

(a, b, x)

sage: a^b + a^b*x

a^b*x + a^b

Note that the patch reverses the order used for printing. AFAIR, it

used to be that we said x^3 < x^2 to be able to print x^3 + x^2.

> Shouldn't we consider the degree of the power is 1, so at least the

> above case is solved.

> Or do something more complicated comparing exponents...

If you always take the degree of power objects to be 1, you end up

saying a^b == a^c. Something more complicated is required there...

> I do not understand the comment of William Stein about symbols

> ordering.

> When a polynomial ring is created in Sage, the variables are ordered

> according to the order they were "created", i.e.

> PR.<x,y> = PolynomialRing(QQ) will result in x > y

> and PR.<y,x> = PolynomialRing(QQ) in y > x

He's probably trying to describe this order:

sage: var('z,x,y,a')

(z, x, y, a)

sage: a+x+y+z

a + x + y + z

Cheers,

Burcin

Oct 2, 2010, 6:30:27 AM10/2/10

to pynac-devel

Hi,

I managed (?) to get mercurial to produce a patch to be applied after

yours at :

http://perso.telecom-paristech.fr/~flori/pynac_order-2.patch

Hope that step did not introduce any problem.

I left the code for comparing symbols as is (i.e. it reverse the

string comparison of C++).

And I did not have much time to test it, but it is a first step.

Cheers,

I managed (?) to get mercurial to produce a patch to be applied after

yours at :

http://perso.telecom-paristech.fr/~flori/pynac_order-2.patch

Hope that step did not introduce any problem.

I left the code for comparing symbols as is (i.e. it reverse the

string comparison of C++).

And I did not have much time to test it, but it is a first step.

Cheers,

Oct 1, 2010, 5:05:10 PM10/1/10

to pynac-devel

Hi,

On 1 oct, 20:59, Burcin Erocal <bur...@erocal.org> wrote:

> Hi,

>

> This discussion should really be on pynac-devel. I set the Reply-To

> address accordingly. I hope it works. ;)

Thanks !

was greater than x (don't remember why, I must have changed something

somewhere...), so it compared to compare the exponent in a^b (b) and

the exponent of x (1) which returned b > 1 and a^b > x so that I got

a^b*x < a^b

>

> Note that the patch reverses the order used for printing. AFAIR, it

> used to be that we said x^3 < x^2 to be able to print x^3 + x^2.

>

> > Shouldn't we consider the degree of the power is 1, so at least the

> > above case is solved.

> > Or do something more complicated comparing exponents...

>

> If you always take the degree of power objects to be 1, you end up

> saying a^b == a^c. Something more complicated is required there...

>

For such expression, it is the compare_s_t_power function which is

called and that one will compare the exponents, so that should not be

a problem.

> > I do not understand the comment of William Stein about symbols

> > ordering.

> > When a polynomial ring is created in Sage, the variables are ordered

> > according to the order they were "created", i.e.

> > PR.<x,y> = PolynomialRing(QQ) will result in x > y

> > and PR.<y,x> = PolynomialRing(QQ) in y > x

>

> He's probably trying to describe this order:

>

> sage: var('z,x,y,a')

> (z, x, y, a)

> sage: a+x+y+z

> a + x + y + z

>

I think you are right.

My concern is that it is not the kind of lexicographic order that is

used by PolynomialRing, but that is just a detail.

Both should be ok, but one has to be chosen.

I have working code for printing.

I must now produce a clean patch file (which looks harder to me) so

other people can test it.

Cheers,

On 1 oct, 20:59, Burcin Erocal <bur...@erocal.org> wrote:

> Hi,

>

> This discussion should really be on pynac-devel. I set the Reply-To

> address accordingly. I hope it works. ;)

> It looks like you just need to return a^b < a^b*x. This is also what we

> have now:

>

> sage: var('a,b,x')

> (a, b, x)

> sage: a^b + a^b*x

> a^b*x + a^b

As I changed some function it turned out to be the converse because a
> have now:

>

> sage: var('a,b,x')

> (a, b, x)

> sage: a^b + a^b*x

> a^b*x + a^b

was greater than x (don't remember why, I must have changed something

somewhere...), so it compared to compare the exponent in a^b (b) and

the exponent of x (1) which returned b > 1 and a^b > x so that I got

a^b*x < a^b

>

> Note that the patch reverses the order used for printing. AFAIR, it

> used to be that we said x^3 < x^2 to be able to print x^3 + x^2.

>

> > Shouldn't we consider the degree of the power is 1, so at least the

> > above case is solved.

> > Or do something more complicated comparing exponents...

>

> If you always take the degree of power objects to be 1, you end up

> saying a^b == a^c. Something more complicated is required there...

>

called and that one will compare the exponents, so that should not be

a problem.

> > I do not understand the comment of William Stein about symbols

> > ordering.

> > When a polynomial ring is created in Sage, the variables are ordered

> > according to the order they were "created", i.e.

> > PR.<x,y> = PolynomialRing(QQ) will result in x > y

> > and PR.<y,x> = PolynomialRing(QQ) in y > x

>

> He's probably trying to describe this order:

>

> sage: var('z,x,y,a')

> (z, x, y, a)

> sage: a+x+y+z

> a + x + y + z

>

My concern is that it is not the kind of lexicographic order that is

used by PolynomialRing, but that is just a detail.

Both should be ok, but one has to be chosen.

I have working code for printing.

I must now produce a clean patch file (which looks harder to me) so

other people can test it.

Cheers,

Oct 4, 2010, 1:00:51 PM10/4/10

to pynac-devel

Hi,

I put a different version of the patch at the same adress.

It treats comparison differently according to whether we are in a mul

or an add object.

However I did it in a kind of dirty way :

- virtualized get_sorted_seq, overrided it in mul objects...

- ..using a flag to know if we are inside a mul or add object.

Don't know how you would like to do it.

As far as symbolic exponents are concerned, we could add an exponent

member to mul object and compute it when we want to print as you did

with sorted_seq.

We would use it to do a good comparison of exponents.

Of course that would be slower...

Right now the total_degree function does not make much sense because

of the symbolic exponents within power objects which count for 1 and

we still have :

sage: x*a^b+a^b

a^b + a^b*x

and inconsistent ordering for expressions mixing power objects and mul

objects with different kind of exponents :

sage: x^(a+b)+x^3 + x^4+a^4+a^2*x^2

a^2*x^2 + x^(a + b) + a^4 + x^4 + x^3

because I always compare exponents for power objects, but not for mul

and power objects.

If you agree with that idea, i can do it and we would have something

much more consistent.

Cheers,

I put a different version of the patch at the same adress.

It treats comparison differently according to whether we are in a mul

or an add object.

However I did it in a kind of dirty way :

- virtualized get_sorted_seq, overrided it in mul objects...

- ..using a flag to know if we are inside a mul or add object.

Don't know how you would like to do it.

As far as symbolic exponents are concerned, we could add an exponent

member to mul object and compute it when we want to print as you did

with sorted_seq.

We would use it to do a good comparison of exponents.

Of course that would be slower...

Right now the total_degree function does not make much sense because

of the symbolic exponents within power objects which count for 1 and

we still have :

sage: x*a^b+a^b

a^b + a^b*x

and inconsistent ordering for expressions mixing power objects and mul

objects with different kind of exponents :

sage: x^(a+b)+x^3 + x^4+a^4+a^2*x^2

a^2*x^2 + x^(a + b) + a^4 + x^4 + x^3

because I always compare exponents for power objects, but not for mul

and power objects.

If you agree with that idea, i can do it and we would have something

much more consistent.

Cheers,

Oct 6, 2010, 3:15:06 AM10/6/10

to pynac...@googlegroups.com

Hi Jean-Pierre,

Thank you for the patch. I don't have time to test it right now, but

at least it applies cleanly on top of mine.

I will be offline for a couple of days at a meeting by a lake side

conference center in Austria, which unfortunately doesn't have wifi. I

should be able to respond to your message properly when I get back in

the weekend.

BTW, does your patch add a comparison operator for functions? We could

sort them alphabetically based on the function name for example. This

would resolve #9632.

Cheers,

Burcin

Oct 6, 2010, 4:15:27 AM10/6/10

to pynac-devel

Hi,

Answer when you can, no problem, I also have lots of urgent things to

do right now...

- I fear I introduced some new inconsistencies while tweaking

everything, I will run more tests, but I posted a irst version of the

patch to get some feedback.

- I didn't think of sorting the functions because i don't use any,

I'll add that.

- I'll also add functions to get "real" total exponents in my previous

post and (try to) properly compare symbolic (or not with hold ?)

exponents of pow objects wrapped inside mul objects.

- I did not take into account the fact that expressions can now be

held, so maybe some of the assumptions I made are not true anymore (no

mul inside a mul e.g., everything is noted in comments whithin the

source code), I'll try to get what hold exactly does, test and fix it.

Cheers,

Answer when you can, no problem, I also have lots of urgent things to

do right now...

- I fear I introduced some new inconsistencies while tweaking

everything, I will run more tests, but I posted a irst version of the

patch to get some feedback.

- I didn't think of sorting the functions because i don't use any,

I'll add that.

- I'll also add functions to get "real" total exponents in my previous

post and (try to) properly compare symbolic (or not with hold ?)

exponents of pow objects wrapped inside mul objects.

- I did not take into account the fact that expressions can now be

held, so maybe some of the assumptions I made are not true anymore (no

mul inside a mul e.g., everything is noted in comments whithin the

source code), I'll try to get what hold exactly does, test and fix it.

Cheers,

Oct 7, 2010, 6:39:57 AM10/7/10

to pynac-devel

Hi,

> - I didn't think of sorting the functions because i don't use any,

> I'll add that.

A new version is up with code for functions and fderivatives (http://

perso.telecom-paristech.fr.fr/~flori/pynac_order-2.patch).

> - I'll also add functions to get "real" total exponents in my previous

> post and (try to) properly compare symbolic (or not with hold ?)

> exponents of pow objects wrapped inside mul objects.

Not done yet, will do it later, surely not before end of october.

> - I did not take into account the fact that expressions can now be

> held, so maybe some of the assumptions I made are not true anymore (no

> mul inside a mul e.g., everything is noted in comments whithin the

> source code), I'll try to get what hold exactly does, test and fix it.

Not done yet, working on it soon.

I made some comments in a new thread.

Cheers,

> - I didn't think of sorting the functions because i don't use any,

> I'll add that.

perso.telecom-paristech.fr.fr/~flori/pynac_order-2.patch).

> - I'll also add functions to get "real" total exponents in my previous

> post and (try to) properly compare symbolic (or not with hold ?)

> exponents of pow objects wrapped inside mul objects.

> - I did not take into account the fact that expressions can now be

> held, so maybe some of the assumptions I made are not true anymore (no

> mul inside a mul e.g., everything is noted in comments whithin the

> source code), I'll try to get what hold exactly does, test and fix it.

I made some comments in a new thread.

Cheers,

Oct 8, 2010, 6:03:04 AM10/8/10

to pynac-devel

By the way, looking at http://trac.sagemath.org/sage_trac/ticket/10053

, I realized that the restored GiNaC order (so mainly comparing hash

values) is called when one calls cmp(a,b) or a.__cmp__(b).

I guess that should also be changed to use the order used for printing.

, I realized that the restored GiNaC order (so mainly comparing hash

values) is called when one calls cmp(a,b) or a.__cmp__(b).

I guess that should also be changed to use the order used for printing.

Oct 8, 2010, 8:00:29 PM10/8/10

to pynac-devel

The version up now seems in a good shape.

http://perso.telecom-paristech.fr/pynac_order-2.patch

The few tests I ran for held expressions were ok.

I forgot the idea of computing total exponents, that would slow

everything down and would only introduce problems.

The comparison is made kind of like before : symbolic exponents are

wrapped inside power objects so that they count for 1 in total

degrees, and those power kind of act like "new" variables.

We get x^2 > x^a > x^b > x for example.

The main thing I'm not completely happy with is the way we compare

complex numbers with norm.

We could maybe use GiNaC function.

However when I tried it with hold, I got strange errors :

HIT STUB : Number_T_to... unable...

happening in numeric.cpp.

The code I used is still within order.cpp but commented out.

http://perso.telecom-paristech.fr/pynac_order-2.patch

The few tests I ran for held expressions were ok.

I forgot the idea of computing total exponents, that would slow

everything down and would only introduce problems.

The comparison is made kind of like before : symbolic exponents are

wrapped inside power objects so that they count for 1 in total

degrees, and those power kind of act like "new" variables.

We get x^2 > x^a > x^b > x for example.

The main thing I'm not completely happy with is the way we compare

complex numbers with norm.

We could maybe use GiNaC function.

However when I tried it with hold, I got strange errors :

HIT STUB : Number_T_to... unable...

happening in numeric.cpp.

The code I used is still within order.cpp but commented out.

Oct 10, 2010, 6:34:24 PM10/10/10

to pynac...@googlegroups.com

Hi,

On Fri, 8 Oct 2010 17:00:29 -0700 (PDT)

Jean-Pierre Flori <jpf...@gmail.com> wrote:

> The version up now seems in a good shape.

> http://perso.telecom-paristech.fr/pynac_order-2.patch

This address gives a 404 error for me. Can you attach the patch to the

trac ticket?

> The few tests I ran for held expressions were ok.

>

> I forgot the idea of computing total exponents, that would slow

> everything down and would only introduce problems.

> The comparison is made kind of like before : symbolic exponents are

> wrapped inside power objects so that they count for 1 in total

> degrees, and those power kind of act like "new" variables.

> We get x^2 > x^a > x^b > x for example.

At the moment, we have this:

sage: var('a,b')

(a, b)

sage: x^2 + x^a + x^b + x

x^b + x^a + x^2 + x

How come the new order is different? Note that all these are power

objects, so the comparison functions of mul are not relevant here.

> The main thing I'm not completely happy with is the way we compare

> complex numbers with norm.

> We could maybe use GiNaC function.

> However when I tried it with hold, I got strange errors :

> HIT STUB : Number_T_to... unable...

> happening in numeric.cpp.

> The code I used is still within order.cpp but commented out.

I can take a look at this once I download the patch.

Thank you.

Burcin

Oct 10, 2010, 6:58:28 PM10/10/10

to pynac...@googlegroups.com

I guess we'll have to do this.

Using a consistent order for __cmp__() is enough, so the printing order

is not necessary. Keeping the GiNaC order for __cmp__() would make it

much faster, though this will be

* very confusing to users,

* not consistent between different runs of Sage

There is not much of a choice really.

We will also have to change the operands(), iterator(), etc. functions

to address the operands in the printing order.

Cheers,

Burcin

Oct 11, 2010, 2:23:55 AM10/11/10

to pynac-devel

On 11 oct, 00:34, Burcin Erocal <bur...@erocal.org> wrote:

> Hi,

>

> On Fri, 8 Oct 2010 17:00:29 -0700 (PDT)

>

> Jean-Pierre Flori <jpfl...@gmail.com> wrote:

> > The version up now seems in a good shape.

> >http://perso.telecom-paristech.fr/pynac_order-2.patch

>

> This address gives a 404 error for me. Can you attach the patch to the

> trac ticket?

>

I'll post both your patch and mine on the trac server asap.
> > The version up now seems in a good shape.

> >http://perso.telecom-paristech.fr/pynac_order-2.patch

>

> This address gives a 404 error for me. Can you attach the patch to the

> trac ticket?

>

> > I forgot the idea of computing total exponents, that would slow

> > everything down and would only introduce problems.

> > The comparison is made kind of like before : symbolic exponents are

> > wrapped inside power objects so that they count for 1 in total

> > degrees, and those power kind of act like "new" variables.

> > We get x^2 > x^a > x^b > x for example.

>

> At the moment, we have this:

>

> sage: var('a,b')

> (a, b)

> sage: x^2 + x^a + x^b + x

> x^b + x^a + x^2 + x

>

> How come the new order is different? Note that all these are power

> objects, so the comparison functions of mul are not relevant here.

>

total degrees.

Previously we got x^b*y < y^3 and x^b*x^2 < x^4 but x^b > x^4...

So my idea was to consider "x^b" as a "new symbol", bigger than "x"

and of degree "1".

So we still have x^b*y < y^3 and x^b*x^2 < x^4 but now x^b < x^4.

JP

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu