145 Reputation

5 Badges

1 years, 69 days

MaplePrimes Activity

These are replies submitted by Stretto

@Carl Love 


This is the problem:


Maple has defines the most common command to be something different and then returns meaningless results. You say that gcd and mod are for polynomials and that for integers, the most common case, we have to prefix i... That is ass-backwards.


gcd and mod should be for integer(of which mod can be generalized to real w.l.o.g.) and pgcd and pmod should then be used for polynomials...


One doesn't make the most common cause use the most uncommon syntax. In all number theory books they will define gcd and mod for integers, not polynomials... not until after the fact.


Also, the definition for the gcd and mod of polynomials extends that over integers, so maple is crapping out and producing invalid results when it is clear that this is an issue with maples design... not mine.


For example, suppose one day that the government decides to redefine red = go and green = stop... and then gives everyone a ticket and blames them for all the crashes.. Is this logical? Why should have have to learn to jump through hoops just because maple got it wrong?


More importantly, if the inputs in to these functions are not defined then how the hell can it make any decisions about anything?

No one has explained to me why gcd(a,b) returns 1 when a and b are not defined! It is immaterial if gcd only accepts polynomials. This would be a programming bug in any normal programming language. It's not correct behavior. The goal of any programming language(including maple) is not to make life for the programmer hell by having obscure side conditions that can be difficult to detect.


How many people do you think that come to maple for the first time and are fully familiar with mod outside of maple will know that it is meant for polynomials? Ok, fine, they will learn that it is for polynomials... but that doesn't then explain why gcd(a,b) = 1 when a and b are undefined.


This is like defining sin(x)/x = 432 when x = 0. It is illogical and counterproductive.


Maple is wrong in this case. Ideally it would be fixed. The fact that mod does work for explicit integers FURTHERS the problem because now mod is overload to work for integers in some cases and not others, but you tell me it only works for polynomials? What precisely is a polynomial to maple? is 3 not a polynomial? is q a polynomial?

These behaviors are wrong. Sure one can work around them, but the mere fact that one has to do so is why they are wrong.


I'm not talking about what maple does, it does what it does, I'm talking about what is logically correct... and in most cases what is logically correct is determined by precedence. If I open up the top 50 programming languages they all use mod in the exact same way and there is no problem. Maple chose to behave different for an arbitrary purpose that seems to only produce extra hoops. The main issue is that it silently gives invalid results rather than an error. That is unacceptable. How hard is it for maple to check if the arugments exist?







That works but not what I'm looking for. I do not want to emulate the modulo function. I want to know why it doesn't work in general?


fmod doesn't work outside the plot


f := n->n*(fmod(n, 4));
                          2 fmod(2, 4)

I don't understand why these functions just don't behave in the obvious way. It's really bizzare to me that I have so much trouble with certain functionality in maple. If I do x mod 3 I expect x to be modded by 3 regardless if it is a variable an integer or a real.


I know I can define the the function but why isn't maple's mod function defined for these most common cases in the first place when used with variables such as in functions? It seems that maple really loves to try to compute something before it should be and return an invalid result.


plot( x mod 3,x=-5..5);


It should work, why doesn't it? Is it because maple tries to compute x mod 3 and says "Oh, x is a variable, so let's just return x instead"? Or what?


The reason why this is a problem is because in virtually every other CAS and in most programming languages, they work logically and evaluate expressions as they are composed without and strange "logic" that produces invalid results. If I never know what the heck is going on I'll keep forgetting and wasting my time.




@Carl Love 


That seems wrong behavior: " If c is any common divisor of p and q, then c divides their GCD. "

where p and q are polynomials. a and b are polynomials... constant polynomials or unknown polynomials.

a and b are not defined anywhere, so how could it even know if there is a common factor or not? They could be polynomials with common factors or not. Usually when maple cannot unambiguously do something it just returns the expression.


Can you explain to me why maple thinks a and be have no divisors? [Remember, they are not defined anywhere so I'm having a hard time figuring out how it can make any decision about them]


@vv I'm not sure if this is what I want. This seems to be to set the rotation angle by code. I am stricktly talking about interating with the plot using the mouse. It seems to depend the position of the mouse... which is not what I want. This makes it very hard to control. It just simply be rotated relative to the mouse. Of course, we only have 2D so I guess this is why they use the height, but it's very hard to control.

@Christian Wolinski 


Thanks... is there any way to set it black? I don't understanding the coloring. I have set and xyz scheme but I can't get black. Is there any way to color based on x y and z for black? (then I could just set z = 0 to be RGB(0,0,0))





@acer Thanks, 2nd case.

@Christian Wolinski 


The case I gave above was just an example. I need a general understanding of what maple is doing... why it is creating 2x(x)(x).



and I remember that, but since I'm not dealing with a polynomnial I figured it wouldn't work... Why would it? If someone told me to pick up that apple and pointed to a bannana why would I think that makes sense?

It makes sense to have something like convert(f, removeBigO)?

@Thomas Richard 


The problem seems that when you highlight a word such as double clicking on it the F2 opens up the wrong info. Without highlighting it seems to work.


Also, it seems that F1 nor F2 work in a code edit region!



I thought about that but the `;` terminates a statement. How does maple know that the sum is part of the definition of g? When I see that I see two statements:


g := x->local j;





@Carl Love 


Is there any way to evaluate some functions. In my expanion there are some factors that are 0 as they involve sin terms evaluated at integers but the expression is that on a function sin(f(x)) + f(x). I want to evaluate the sin terms(setting them to 0 in this case) but not the non sin terms(which are unknown).




Can you ever come up with a reason why an nx1 matrix multiplied pointwise by a n vector could ever cause problem? Seems to me that they are completely equivalent structures and where ever one is used another can be used. That is,, is it not true that an n-dimensional vector space is isomorphic to nx1 and 1xn matricies?  If that is the case then there is no reason why it can't be simplified when dealing with pointwise multiplication.

A*~a = a*~A = B*~a = a*~B

for a a n-vec and A a 1xn and B a nx1.


We are not talking about matrix multiplication where the dimensions must be compatible, we are talking about element wise multiplication.


The fact that your rule to solv ethe problem is simply an obfusication of syntax proves this. Maple could internally rewrite every syntax for us and the arbitrary distinction is not then required.


Unless you can prove that it can't behave this way(but you already have given a syntax that proves it can, at least in this specific case).


[So, maple could, internally require every pointwise operation of a 1xn or nx1 matrix with a n-vector without issue and ide that excess syntax from us without any potential problems, so why force us to jump through such hoops that are meaningless?]





@Carl Love Thanks, works well. Is there a simple way to control amount of interpolation from constant to whatever?




Thanks, that works! Is there a simple way to interpolate to get a smooth curve?


listplot(S, smooth);


1 2 3 4 5 6 Page 4 of 6