roman_pearce

Mr. Roman Pearce

1678 Reputation

19 Badges

20 years, 215 days
CECM/SFU
Research Associate
Abbotsford, British Columbia, Canada

I am a research associate at Simon Fraser University and a member of the Computer Algebra Group at the CECM.

MaplePrimes Activity


These are replies submitted by roman_pearce

The exponents must be rational numbers. Maple's polynomial routines do not generally support polynomials with irrational, transcendental, or parametric exponents, so there's not very much you can do with things like x^Pi or x^n. The exponents should be non-negative integers. Extending the command to make a common basis for parametric exponents would solve this problem, but that seems like a research question. Maybe build up relations among the exponents and eliminate variables. In theory you could resolve all kinds of crazy things and turn them into polynomials at which point Maple could possibly do something useful with them, but I'm not sure how tractable this would be or what the payoff is, aside from processing bizarre formulas. Maybe it would be cool. Keep in mind, Groebner:-SubstituteRootOfs is just a quick and dirty replacement mechanism. It's goal was to be a fast preprocessor for computing Groebner bases, in cases where that makes sense. Hence the restriction to rational exponents which can be converted to integers.
The exponents must be rational numbers. Maple's polynomial routines do not generally support polynomials with irrational, transcendental, or parametric exponents, so there's not very much you can do with things like x^Pi or x^n. The exponents should be non-negative integers. Extending the command to make a common basis for parametric exponents would solve this problem, but that seems like a research question. Maybe build up relations among the exponents and eliminate variables. In theory you could resolve all kinds of crazy things and turn them into polynomials at which point Maple could possibly do something useful with them, but I'm not sure how tractable this would be or what the payoff is, aside from processing bizarre formulas. Maybe it would be cool. Keep in mind, Groebner:-SubstituteRootOfs is just a quick and dirty replacement mechanism. It's goal was to be a fast preprocessor for computing Groebner bases, in cases where that makes sense. Hence the restriction to rational exponents which can be converted to integers.
It returns a sequence four sets: F,R,M,V where F is a set of forward substitutions that replace all RootOfs, radicals, and functions with variables, R is a set of reverse substitutions, M is a set of minimal polynomials, and V is the set of variables which are to be reduced by the minimal polynomials. The command preserves algebraic relations so that, for example, sqrt(2) and RootOf(z^2-2,index=1) are replaced by the same variable, and it eliminates fractional exponents using a common denominator. We needed it for the Groebner package because the internal routines expect polynomials, so everything had to be turned into a polynomial or you could get strange inconsistencies in the algorithms. I'm starting to think that Maple needs something like this more generally. Maybe not for most users, but it might be a nice compliment to frontend for advanced users and programmers. It has some limitations. It is not aware of algebraic relations between functions, for example, if sin(x) and cos(x) they will be replaced but the relation sin(x)^2+cos(x)^2=1 will not be noticed or added to M. Maybe we could do that using FunctionAdvisor.
It returns a sequence four sets: F,R,M,V where F is a set of forward substitutions that replace all RootOfs, radicals, and functions with variables, R is a set of reverse substitutions, M is a set of minimal polynomials, and V is the set of variables which are to be reduced by the minimal polynomials. The command preserves algebraic relations so that, for example, sqrt(2) and RootOf(z^2-2,index=1) are replaced by the same variable, and it eliminates fractional exponents using a common denominator. We needed it for the Groebner package because the internal routines expect polynomials, so everything had to be turned into a polynomial or you could get strange inconsistencies in the algorithms. I'm starting to think that Maple needs something like this more generally. Maybe not for most users, but it might be a nice compliment to frontend for advanced users and programmers. It has some limitations. It is not aware of algebraic relations between functions, for example, if sin(x) and cos(x) they will be replaced but the relation sin(x)^2+cos(x)^2=1 will not be noticed or added to M. Maybe we could do that using FunctionAdvisor.

I use  \MapleInput{x \char94 2}

I use  \MapleInput{x \char94 2}

Yes, the Maple interface is a separate process.
I totally agree, there's no point in trying to parallelize if your software is slow.
As far as I understand the current situation, with code in Maple language being 500-1000 slower than, say, in C, it doesn't have much sense to use parallel programming for Maple code...

I don't think that's true. Higher level algorithms are written in Maple and they must eventually be parallelized, because the lower level operations (which may be written in C) will hit Ahmdal's law. Think of an algorithm that uses chinese remaindering - the subproblems may be too small to parallelize. There are lots of opportunities like this and I think the task model is the right one to use. Ultimately though we will need both "top-down" parallelization in the Maple library and "bottom-up" parallelization at the C level to take advantage of hundreds of cores.
I really liked the series!
I assume that the goal for everyone is fast numerical computation so I ask myself the question: Why are not all loops by default converted to C ? Note: the goal for the Maple language was historically not fast numerical computation. It was designed for general algebra programs, and it is used for the Maple library. It was also designed for interactive computation, so variables have no datatype, etc, like in C. I agree it would be nice to have the speed of C for numerical loops, but that's what option autocompile is for.

Please don't use Flash.  It just serves to make the website less accessible and more difficult to maintain.  Also, would it even be viewable on a netbook?

I think MaplePrimes is pretty good overall, and availability is the main issue I would address. Secondary is rendering speed.  Not sure why, but in some browsers (Firefox, Safari) opening lots of pages in new tabs is incredibly slow.  It could be a browser issue, in which case I wouldn't worry about it. If you insist on adding new features, how about an ability for readers to vote blog posts onto the front page. Like if a post gets 10 votes it goes to the front page. This would cut down on maintenance time. Other than that, we need more content, but this is hard to do. The content that would be most interesting to me would be discussions about Maple development, but you may not want to post all the gory details. Maybe post writeups similar to ?whatsnew about specific features and how to use them. We could do overlooked features in the current release and interesting features that may be in the next release. For example, I could contribute an article on sdmp, Marc Moreno would probably do a post about modpn and RegularChains, etc. Just ask people. I know there are lots of other unsung projects inside the company that deserve mention. This sort of thing is interesting. I also realize nobody ever has time, but it only takes an hour to write something usually. How does the company feel about being more open about ongoing work? I know it would find a big audience here, and I think it would make the marketing of the eventual release a lot easier. Right now it often feels like a "cold call" where you see what's been done, but never the motivation or ideas behind it. MaplePrimes is the perfect place to address that.
You can assume that f=0 is equivalent to numer(f)=0 and do coeffs(expand(numer(f)), zin); Then check that denom(f) is not zero at whatever values of zin you end up using.
You can assume that f=0 is equivalent to numer(f)=0 and do coeffs(expand(numer(f)), zin); Then check that denom(f) is not zero at whatever values of zin you end up using.
First 13 14 15 16 17 18 19 Last Page 15 of 39