sursumCorda

1174 Reputation

13 Badges

2 years, 76 days

MaplePrimes Activity


These are replies submitted by sursumCorda

@bathudaide You may replace all uses of the external FGb package with the built-in Groebner package (although this is not an easy task.). For instance, “FGb:-fgb_gbasis” should be replaced by “Groebner:-Basis”, and “FGb:-fgb_hilbert” should be replaced by “PolynomialIdeals:-HilbertDimension”. The problem is that the source code is not immediately available, so it requires a lot of work to complete the modification.

Some notes:

  1. The only way to numerically solve medium-scale SDP problems in Maple is still to call some Python-based solver using Maple's Python package (or to invoke some MatLab-based solver using Maple's MatLab package). 
  2. Maple's Optimization module is based on the NAG library, and NAG does provide one SDP solver, but unfortunately, Maple does not yet support this routine. 
  3. There exist another third-party SDP solver for Maple: SDPTools. (The semidefinite is so old that I cannot find its code…) However, I do not know how to use it.

Besides, there exists a general evalb function, `property/Evalb`, in Maple, which may run faster than the analogous top-level functions for a lot of non-numeric input (as there is no additional overhead). However, this function only accepts one inequality (so neither `=` nor `<>` is valid). 

@nm As a side note, according to 

showstat(is, 2 .. 3);

is := proc()
       ...
   2       FAIL
       elif _npassed = 1 and type(_passed[1],'relation(numeric)') then
   3       evalb(_passed)
       ...
end

calling `is` will automatically invoke `evalb` if the input is of type 'numeric', so when using `is` it is always unnecessary to check if the input is of type 'numeric' by hand. 
I believe that another safe method is: 

if signum(0, n - m, 0)::{0, 1} then
    "yes"
else
    "no"
fi:

(By the way, even though the documentation of `verify/greater_than` refers to `signum`, the use of “verify(n, m, 'greater_equal')” is, unfortunately, unsafe.) 

@Carl Love Thanks. Strangely, if _EnvTry is not set to 'hard', the result will not be incorrect (but that does not make sense, since coulditbe just outputs FAIL this time …). 

@ecterrab Thanks for the prompt fix! There are no errors now.

@Christian Wolinski Thanks for the correction. I shall submit a new SCR soon.

@Carl Love Many thanks! So this means that neither coulditbe nor RealDomain:-solve is that reliable … I have just submitted a SCR. 

@dharr Thanks. This command is powerful! But it seems that some heavy post-processing will have to be done, since the help page says: 

This command returns …  has exactly n distinct real solutions …. 

So the condition p^2*q + 3*p*r - 4*q^2 > 0 cannot be equivalent to condition q>0. For instance, the returned dec does not consider (𝑥-1)³ (corresponding to the case p = -3, q = 3, and r = -1). (By the way, I think that [p, q, r] (the fourth argument) should be changed into [].) 

@Carl Love This is very useful!
Maple's select function just filters items based on a criterion, and so do Mma's Select and Cases, but there exist two generalized functions in Mma: SequenceCases and SubsetCases (where the former only finds consecutive sequences). Although these two generalized functions are not commonly used, they are still useful sometimes (for instance, the latter may be used to enumerate cycles of some length in arbitrary graphs). However, I cannot find an equivalent function that can filter (sub-)sequences satisfying certain functions (or matching certain patterns) in Maple. Is there an (elegant) way to simulate the two Mma functions in Maple? 

@Carl Love Thanks. I suspect this is because Maple is too "smart" to ignore argument checking when not all parameters are used, but I'm more inclined to believe this is simply a hidden bug. 

@Carl Love Many thanks.

There exists another problem: I think that 

f := overload([proc(a::seq(Non(2)), b::2, c::seq(Non(3)), d::3)
	option overload:
	[a, b, c, d, _rest]
end, ERROR]):

is equivalent to 

g := overload([proc(a::seq(Non(2)), b::2, c::seq(Non(3)), d::3)
	option overload:
	[args]
end, ERROR]):

yet g(4, 3, 2, 1); does not work as desired. It seems like I have to write out the parameters explicitly (even if they will never be used in the procedure), but I cannot find any mention of this in the help page. Is this limitation documented?
Currently, I have to write something like 

overload([proc(a::seq(Non(2)), b::2, c::seq(Non(3)), d::3)
    options overload;
    'a, b, c, d': true
end, unapply(false)]);

where the italicized part makes no sense ….

@acer & @Thomas Richard I believe that if certain statements could be invoked in function call form, there would be no dilemma about the ending delimiters.
For instance, instead of using

if A then B elif C then D else E fi;

or

if A then
    B;
elif C then
    D;
else
    E;
end if

I can simply use 

convert([A, B, C, D, E], `if`); # Note that this is not the documented `convert/ifelse`

or

ifelse(A, B, ifelse(C, D, E)) # which is not obsolete yet does not seem to be couraged 

(or even a (flat) piecewise function) and now I don't need to worry about whether to write fi or end if. However, I don't why Maple doesn't support compound expressions (while supporting expression sequences), which makes the use of the function form largely useless (for example, I cannot use something like `if`(a, b; c, d; e) …). 

@Thomas Richard Thanks. Long ending delimiters are often more readable in nested proc/module/try/use, but I think it's better to keep ending delimiters of proc/module/try/use consistent when setting interface('longdelim' = false)
(Another inconsistency is that while some other statements can be embedded as an expression or within an expression (probably by enclosing it in parentheses). the use statement can still only be used as a stand-alone statement.) 

@Carl Love Thanks. This workaround is simple but really effective. If this potential bug (?) can be fixed in the future, it will be more convenient to compress large numbers of cumbersome conditional cases and awkward looping constructs into a few succinct and elegant lines of pattern specifications (although pattern matching does not seem to be a Maple idiom …).  

Seems to me if it gets stuck on 18 decimal digit integer, maybe it's not the best default method...

The default method seems to be good enough in general cases 

forget(ifactor):seq(time[real](ifactor(2**(n-1)+~[$1e4],'mpqs')),n=16..64,8);
      0.694, 0.785, 1.065, 3.407, 10.953, 47.328, 146.828

forget(ifactor):seq(time[real](ifactor(2**(n-1)+~[$1e4],'morrbril')),n=16..64,8);
       0.763, 0.867, 1.027, 3.829, 9.016, 25.598, 48.291

forget(ifactor):seq(time[real](ifactor(2**(n-1)+~[$1e4],'squfof')),n=16..64,8);
      0.685, 0.901, 1.200, 3.463, 11.968, 68.843, 363.656

forget(ifactor):seq(time[real](ifactor(2**(n-1)+~[$1e4],'pollard')),n=16..64,8);
       0.760, 0.809, 1.106, 3.679, 9.265, 30.781, 129.406

forget(ifactor):seq(time[real](ifactor(2**(n-1)+~[$1e4],'lenstra')),n=16..64,8);
      0.674, 0.944, 1.147, 5.713, 28.875, 111.687, 322.093

forget(ifactor):seq(time[real](ifactor(2**(n-1)+~[$1e4],'mpqsmixed')),n=16..64,8);
        0.671, 0.793, 1.028, 3.128, 5.263, 8.670, 33.047

forget(ifactor):seq(time[real](ifactor(2**(n-1)+~[$1e4],'mixed')),n=16..64,8);
       0.677, 0.806, 1.085, 3.575, 8.888, 23.312, 46.424

though it still seems a bit slow (compared to some other computer algebra systems) ….

1 2 3 4 5 6 7 Last Page 2 of 22