Carl Love

Carl Love

28050 Reputation

25 Badges

12 years, 336 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@Stretto wrote:

  • You say that gcd and mod are for polynomials and that for integers, the most common case, we have to prefix i.

No, not quite. Integer constants are themselves polynomials, so gcd and mod work fine for them also. So, the most-general commands are gcd and mod and they work for the vast majority of cases, both polynomial and integer. Your trouble comes from passing x, which is explicitly a polynomial, to a command which needs to handle (and distinguish) both polynomials and integers. It is only in this case, where x has no assigned value, that you have to clarify the situation by using irem, so that Maple will know that x represents an integer whose value has yet to be assigned.

Now, are you going to say that there's some math book, in number theory or otherwise, that says that x is not a polynomial? So, you're trying to force Maple to view something that is manifestly a polynomial as if it were an integer whose value hasn't been assigned. That's the unusual case, and it's handled by irem (or igcd).

  • mod can be generalized to real w.l.o.g.

I think that extending the definition to reals does incur a loss of generality (l.o.g.) because when mod is given a fraction, it finds the multiplicative inverse w.r.t. the modulus. So, for example, 7/2 mod 3 = 2 not 1/2

  • gcd and mod should be for integer and pgcd and pmod should then be used for polynomials.

For your personal use, it would be very easy to change gcd as you suggest and to create a pgcd ​​​​​​and pmod. Each of these could be done with 1 short line of code.  Changing mod is a little trickier (because it's builtin and a binary infix operator), but it's also possible.

  • [I]f 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!

As I said in the other thread, if a and b are not defined, then they're explicitly polynomials, as in a = 1*a+0. Does some math book say that a variable with no assigned value, standing alone, is not a polynomial?

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

Personally, I've had no trouble learning Maple, and I did it simply from the help pages, a bit of experimentation, and a bit of reading in these online forums. Overall, it makes more consistent sense to me and has fewer obscure roadblocks than any other language that I know: Basic, Pascal, Algol, Fortran, APL, C, Maxima, Kadol, and dBase/FoxPro.

  • Maple is wrong in this case. Ideally it would be fixed.

The things that you want "fixed" (mod and gcd) cannot be changed (for general release) because there's nearly 30 years of Maple code that relies on their current definitions. But, if you were writing a package for publication, or just wanted something for personal use, it'd be fairly easy to change in those cases.

I would guess that anyone who's used Maple moderately to extensively has a few ideas about how they would make some things different if they were building it from the ground up. One thing that I might do differently would be to have a way to explictly mark things as polynomials (akin to the way that matrices are explicitly marked) so that things like just plain x wouldn't be mistaken for one. 

  • 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?

Integers are polynomials. It works for explicit rational numbers (including integers), algebraic numbers specified in RootOf form, expressions with variables that evaluate to rationals, and matrices of polynomials. It's not true that mod works "for integers in some cases and not others." It works for integers in all cases. An unassigned x is not an integer. That's obvious.

  • What precisely is a polynomial to maple? is 3 not a polynomial? is q a polynomial?

Both 3 and q are polynomials to Maple. Polynomials in Maple are pretty much what you'd expect from the mathematical definition: the algebraic closure of the operations `*` , `+`, and `^` with positive integer exponents over the set of objects of type {constant, name}. Expressed as a recursive type in Maple:

TypeTools:-AddType(
    poly,
    Or({constant, name}, poly^posint, specop(poly, {`*`, `+`}))
);

There is of course already a predefined type polynom. The above is just to make the workings explicit.

It makes no sense for you to compare the way that Maple treats x mod 3 when has no assigned value with any other language that doesn't even allow variables to not be assigned values (i.e., symbolic variables). But if you're willing to make a comparison only among languages that allow symbolic variables, I'd be interested.

@shkarah Post a fully executed worksheet, beginning with restart, that shows your results. And please post it so that it displays in MaplePrimes. Here is my worksheet. The final solutions are mathematically identical to what's shown in the paper; they just need trivial re-arranging to make that obvious. For example, for f[2](x), you just need to distribute the E^2*a/30 over the other terms, reduce the fractions, and substitute alpha for E and eta for x.
 

restart:

N := 2;
F := sum(p^i*f[i](x), i = 0 .. N);
HPMEq := (1 - p)*diff(F, x $ 3) + p*(diff(F, x $ 3) + 2*E*R*diff(F, x)*F + (4 - H)*E^2*diff(F, x));
for i from 0 to N do
    equ[2][i] := coeff(HPMEq, p, i) = 0;
end do;
cond[1][0] := f[0](0) = 1, D(f[0])(0) = 0, D(D(f[0]))(0) = a;
for j to N do
    cond[1][j] := f[j](0) = 0, D(f[j])(0) = 0, D(D(f[j]))(0) = 0;
end do;
Sol:= {};
for i from 0 to N do   
    Sol:= Sol union {dsolve({cond[1][i], eval(equ[2][i], Sol)}, {f[i](x)})}
end do;

2

f[0](x)+p*f[1](x)+p^2*f[2](x)

(1-p)*(diff(diff(diff(f[0](x), x), x), x)+p*(diff(diff(diff(f[1](x), x), x), x))+p^2*(diff(diff(diff(f[2](x), x), x), x)))+p*(diff(diff(diff(f[0](x), x), x), x)+p*(diff(diff(diff(f[1](x), x), x), x))+p^2*(diff(diff(diff(f[2](x), x), x), x))+2*E*R*(diff(f[0](x), x)+p*(diff(f[1](x), x))+p^2*(diff(f[2](x), x)))*(f[0](x)+p*f[1](x)+p^2*f[2](x))+(4-H)*E^2*(diff(f[0](x), x)+p*(diff(f[1](x), x))+p^2*(diff(f[2](x), x))))

diff(diff(diff(f[0](x), x), x), x) = 0

diff(diff(diff(f[1](x), x), x), x)+2*E*R*(diff(f[0](x), x))*f[0](x)+(4-H)*E^2*(diff(f[0](x), x)) = 0

diff(diff(diff(f[2](x), x), x), x)+2*E*R*(diff(f[0](x), x))*f[1](x)+2*E*R*(diff(f[1](x), x))*f[0](x)+(4-H)*E^2*(diff(f[1](x), x)) = 0

f[0](0) = 1, (D(f[0]))(0) = 0, ((D@@2)(f[0]))(0) = a

f[1](0) = 0, (D(f[1]))(0) = 0, ((D@@2)(f[1]))(0) = 0

f[2](0) = 0, (D(f[2]))(0) = 0, ((D@@2)(f[2]))(0) = 0

{}

{f[0](x) = (1/2)*a*x^2+1}

{f[0](x) = (1/2)*a*x^2+1, f[1](x) = E*a*(-(1/120)*a*R*x^6+(1/24)*(E*H-4*E-2*R)*x^4)}

{f[0](x) = (1/2)*a*x^2+1, f[1](x) = E*a*(-(1/120)*a*R*x^6+(1/24)*(E*H-4*E-2*R)*x^4), f[2](x) = (1/30)*E^2*a*((1/360)*R^2*a^2*x^10+(1/336)*(-9*E*H*R*a+36*E*R*a+18*R^2*a)*x^8+(1/120)*(5*E^2*H^2-40*E^2*H-20*E*H*R+80*E^2+80*E*R+20*R^2)*x^6)}

NULL


 

Download HomotopyPerturbation.mw

@Glowing With no decimal point, 1000 means exactly 1000. But 1000. means that there's some uncertainty about the fractional part (there'll always be uncertainty if it represents a measurement rather than a count). Controlling that uncertainty is the essence of decimal computation. If there's no uncertainty, you should represent 1014.1 as 1014+1/10.

Adding an exact integer to a decimal number is like adding apples and orange juice---the former is counted and the latter is measured.

@Scot Gould A better command to check whether an object has a particular type is type not whattype. Note that I said has, not is. An object can have many types; whattype only returns the most superficial of these. So, you can do

`if`(type(x, float), ......)

This can be abbreviated to 

`if`(x::float, ..., ...)

The command convert(..., int) is meant to convert its input to an integral, not to an integer. It is intended for higher mathematical functions that are defined as or can be represented as integrals. If there's no reasonable way to represent its input with integrals, it just returns its input unchanged, which is what's happening in your case. If you wrote a procedure named `convert/integer`, then convert(..., integer) would work.

It will help you to know that all (software) floats in Maple are represented as x = M*10^E where and are integers that can be accessed via (M,E):= op(x). The mantissa and the exponent are always integers. The precision is simply the number of digits of M.

@acer There's a help page for frem, but not for fmod. But a look at the code of `evalf/fmod` shows that all that it does (other than some trivialities concerning 0 and infinity) is

(x,y)-> evalf[2*Digits](x-trunc(x/y)*y)

@Glowing wrote:

  • Some users of Maple actually enjoy this design, so the Maple guys may never fix it, this is really sad.

Whether they enjoy it is largely irrelevant. The significant point is that people have relied on a particular design for years for a huge amount of code that's still in use. The doctrine of backwards compatibility says that a command cannot be changed in a way that will cause existing programs to act differently than what the offcial documentation originally specified.

@Glowing 

I agree with you wholeheartedly that the special evaluation rule of evalf(..., n) or evalf[n](...is not properly documented on its help page. I've learned what I know about it mostly by experimentation. These commands establish a computational "environment" that changes the way that the stuff between the parentheses are evaluated. This is in contrast to the vast majority of commands, which first evaluate what's between the parentheses and then apply the command (as we've been taught to do in elementary arithmetic and algebra).

I think that this is something that cannot be "fixed", due to the need to maintain backwards compatibility. That is, making the desired change to evalf would cause decades of old programs to act differently. 

The alternative would be a new command akin to Mathematica's or Scot Gould's sigfig.

@Stretto Any name---abx---is inherently a monic, first-degree, one-term polynomial. The a and b in gcd(a,b) are simply themselves; they're not placeholders for anything else, such as possibly some more-elaborate polynomials. There needs to be some way to distinguish whether one wants the GCD of integers or polynomials. That's why there are two commands: gcd and igcd. In the case of igcd(a,b), the a and b are placeholders for integers, which is why that command returns unevaluated.

All this is nothing new and has nothing to do with any upgrade. It's explained on the help pages for those commands, and it always has been, as far as I can recall. 

@fatemeh1090

If you look at the matrix extracted from Excel (as shown in the attached worksheet), it's clear that the 1st row is just labelling and the last 10 rows are garbage, not data at all. Thus, I have

R:= upperbound(XL,1) - 11:

to exclude 11 rows. That's the only change that's needed. The end results are very close to the first case because the data for the subsequent three cases are very close to the first case.

Download 3dModelFit.mw

MaplePrimes apparently can't display my worksheet due to the fully displayed matrices, but you should see what I mean when you download it. Here's the plot:

@fatemeh1090 Maple worksheets alone don't contain the data; they only contain what's shown on the screen. In order to duplicate your results, I need the Excel file. Obviously, you need to filter out the Matrix entries that are just labels like "Y" instead of numeric data.

@Kitonum You wrote:

  • It seems that in the second case Maple first rounds each of the operands to 2 digits, and only then performs the calculation.

Yes, that's exactly what happens, and that's by design. This is nothing new.

@fatemeh1090 Please organize the data into a single matrix in Excel. I don't use Excel, so I can't look all over your worksheet for 4 separate groups of data.

Or, put 4 Excel worksheets in your file with each worksheet having a matrix starting in its upper left corner.

@Scot Gould Yes, that's right, they're substituted first. Arithmetic operations between exact rationals (including integers) are done without regard to floating-point arithmetic. So 1014-1007 is reduced to before it's processed by evalf, and 7 can be adequately represented in 2-digit precision.

@fatemeh1090 Great, you have a model that's linear in its parameters, so it should be easy to find the optimal solution.

Can you get the data into Maple with package ExcelTools?

@fatemeh1090 Yes, there's a few things Maple can do. Do you have a theoretical model to fit to this data? Or do you just want a smooth plot of the surface? Or something else? 

First 231 232 233 234 235 236 237 Last Page 233 of 709