Why do you say "possible"? It's clear to me that your code covers all the cases.

First, let's clarify what the problem under discussion is. I see two possibilities:

1. to find any group of coins whose total value exceeds $1 but such that no subset makes exactly $1,
2. to find a group of coins of maximal total value satisfying (1).

Problem (1) feels like a "knapsack problem". (See the Wikipedia arcticle "Knapsack problem".) I am not at all sure about that. The subset sum problem is a relatively easy (NP-complete) case of the knapsack problem (NP-hard). Problem (2) feels like something where you'd have to solve a knapsack problem for each point (coin combination) that you're checking.

We must resort to heuristics. The best heuristic that I've ever learned applies here, and it applies to almost any real-world packing job: "Put the big ones in first". That's what you've done in your informal solution to this problem: You put in the 50-cent piece, then the 20s, then decided you couldn't fit any 10s, then put in the 5.

@abbeykabir The two curves are so close that the difference is not perceivable. You can find the maximum difference between them with the command

LinearAlgebra:-Norm(M[.., 2] - M[.., 3]);

To exchange the horizontal and vertical axes, change M[.., [1,2]] to M[.., [2,1]] and likewise for M[.., [1,3]].

As threads get older, it gets harder and harder to find them. If you have more questions, please make a new thread.

@abbeykabir The two curves are so close that the difference is not perceivable. You can find the maximum difference between them with the command

LinearAlgebra:-Norm(M[.., 2] - M[.., 3]);

To exchange the horizontal and vertical axes, change M[.., [1,2]] to M[.., [2,1]] and likewise for M[.., [1,3]].

As threads get older, it gets harder and harder to find them. If you have more questions, please make a new thread.

@Alejandro Jakubi 

But the second part of my example shows that assuming is not following this design principle (also from ?assuming,details ):

The output is the same as that received by successively doing the following.
  1. Calling assume (to enter assumptions on names).
  2. Entering (and so evaluating under the assumptions) the expression depending on these names.
  3. Removing the assumptions.

The example shows that it is possible to make the assumptions effectively without scanning the procedure.

@Alejandro Jakubi 

But the second part of my example shows that assuming is not following this design principle (also from ?assuming,details ):

The output is the same as that received by successively doing the following.
  1. Calling assume (to enter assumptions on names).
  2. Entering (and so evaluating under the assumptions) the expression depending on these names.
  3. Removing the assumptions.

The example shows that it is possible to make the assumptions effectively without scanning the procedure.

@abbeykabir 

Use option linestyle to the plot command:

plot(
     [M[.., [1,2]], M[.., [1,3]]],
     labels= [time, `error`], legend= [error1, error2],
     linestyle= [dash, dashdot]
);

The possible values for linestyle are solid, dot, dash, dashdot, longdash, spacedash, and spacedot. See ?plot,options .

@abbeykabir 

Use option linestyle to the plot command:

plot(
     [M[.., [1,2]], M[.., [1,3]]],
     labels= [time, `error`], legend= [error1, error2],
     linestyle= [dash, dashdot]
);

The possible values for linestyle are solid, dot, dash, dashdot, longdash, spacedash, and spacedot. See ?plot,options .

@brian bovril 

All I can recommend is practice, asking questions, and constant re-reading of the help pages. Writing programs about primes is a good place to start. My first program, 35 years ago, was a program that generated primes by trial division.

@brian bovril 

All I can recommend is practice, asking questions, and constant re-reading of the help pages. Writing programs about primes is a good place to start. My first program, 35 years ago, was a program that generated primes by trial division.

If you increase Digits over the hardware-float threshold of 15, then the rounding errors disappear.

@abbeykabir

Good question. In M[.., [1,2]], the .. means "take all rows"; and the overall expression means "take all rows and columns 1 & 2 of M". If it was M[[1,2], ..], it would mean "take rows 1 & 2 and all columns". See ?rtable_indexing .

What do you mean by "modify the shape"? The shape is determined by the data. Or do you mean the style, like dashed lines and dotted lines?

@abbeykabir

Good question. In M[.., [1,2]], the .. means "take all rows"; and the overall expression means "take all rows and columns 1 & 2 of M". If it was M[[1,2], ..], it would mean "take rows 1 & 2 and all columns". See ?rtable_indexing .

What do you mean by "modify the shape"? The shape is determined by the data. Or do you mean the style, like dashed lines and dotted lines?

Indeed, you can include the inequalities in the solve command:

solve({x+y+z=6, x^2+y^2+z^2=14, x^3+y^3+z^3=36, x >= y, y >= z});

Indeed, you can include the inequalities in the solve command:

solve({x+y+z=6, x^2+y^2+z^2=14, x^3+y^3+z^3=36, x >= y, y >= z});