A key feature of Maple and other computer algebra systems (CASs) that distinguish them from other mathematical software, including that $2 calculator, is that results are expressed exactly unless an approximation is forced (in this case by evalf or by using a decimal point).

How about providing us with "the" equation that you want to solve?

@acer I am not at all surprised, of course, by the difference between the OP's two timings. On the contrary, I am surprised by a similarity (which may be a coincidence): For the two timings, the ratio (delta time[real]) / (delta ProcessClock) matches to 3 significant digits, those ratios being 1.033e6 and 1.029e6 (and time[real] is only reported to three significant digits anyway). And is nanoseconds the correct unit for ProcessClock? Shouldn't that be microseconds?

I've noticed some other anomalies with ProcessClock that lead me to be skeptical of it.

@Magma The procedure Bases does it:

Bases:= f-> [seq(`if`(g::`^`, op(1,g), g), g= [`if`(f::`*`, op(f), f)])]:

Usage:

Bases(f);

where f is the polynomial, as before.

The complexity of the above code is due to the need to handle the two degenerate cases: factors that don't have an exponent and polynomials that only have a single factor. 
 

@ecterrab But Kitonum does not want to enter any Sum or sum command. I think that you may be confused because he did in fact enter such a command, even though he did not want to. He wants to enter a command akin to

convert((a+b)^n, Sum) assuming n::posint;  #or something similar

and have Maple respond with a summation formula.

Please post your worksheet as an attached file by using green up arrow on the toolbar of the MaplePrimes editor. Please show the execution of the code and be more clear about what you mean by "does not run".

@acer It's a good workaround (for older versions of Maple) that hadn't yet occured to me.

I suspect that when viewed "over an arbitrary field" (as you say in your Question), the 16x16 case is intractable. But I also suspect that when these matrices are used in practice, the field is small and of characteristic 2. This substantially simplifies the computation.

@WarmtenetwerkBEP All of the other Answers (Kitonum, Joe, VV, Acer) will return true if some vertex occurs in some edge, and false otherwise. Apparently, no-one else had difficulty interpreting the quantifications in your Question.

@Rariusz Does V vary with time, t? If so, then it must be considered as a function by dsolve even if it's only specified by numeric data (that's where interpolation comes in).

If, on the other hand, each record of the file (a record being a group of the four numeric values) is specifying a final value of t where the voltage has been constant from time 0 to time t, then you may consider V as a parameter.

@Rariusz It would be a mistake for you to "close this discussion". Once you specify it precisely, we will be able to solve this problem (or perhaps say that more numeric data is required). You'll not find better help anywhere else.

You need to clarify your requirements using more precise quantifiers, which are words or phrases such as those in my title. Your use of the word "one" is especially confusing because it could mean either "any" or "exactly one". So, do you want to determine whether

1. every vertex occurs in some edge?
2. every vertex occurs in exactly one edge?
3. some vertex occurs in some edge?
4. some vertex occurs in exactly one edge?
5. something else?

@vv Yes, seq is usually faster than an equivalent construction with map and/or elementwise operators. This saddens me, because seq's syntax is ugly. For example, seq requires an index variable (in this context).

@Kitonum There's no need for the other return either.

@Christian Wolinski This degree concept is related to exponents, of course, but it's not about the analytic exp or ln functions; it's a purely algebraic concept. And this is not specific to Maple. If you closely read this Wikipedia article on Euclidean domains (and  "read between the lines") you should see that while degree(0) = 0 would be allowed by the definition, it would be inconvenient, because to effectively perform division-with-remainder we want a function deg such that given any nonzero a and b in the domain there exists q and r in the domain such that  a = q*b + r and deg(r) < deg(b). This ensures termination of Euclid's GCD algorithm, among other things. So, if you think about it for a while, you'll see that we need deg(0) < 0. So, deg(0) = -1 would work, but for reasons already given by VV and me, deg(0) = -infinity is more convenient.