#17979: Reimplementation of IntegerListsLex
-------------------------------------+-------------------------------------
Reporter: aschilling | Owner:
Type: defect | Status: needs_work
Priority: blocker | Milestone: sage-6.6
Component: combinatorics | Resolution:
Keywords: days64 | Merged in:
Authors: Bryan Gillespie, | Reviewers:
Anne Schilling, Nicolas M. Thiery | Work issues: support n in an
Report Upstream: N/A | iterable
Branch: | Commit:
public/ticket/17979 | 3efcb0a067bb039d28d29b3fd8c9115c18c90d15
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by ncohen):
Hellooooo,
> The length of a list is the number of its entries, including entries of
size zero. i.e. [2, 0, 1, 0] is a list of length 4. It is equivalent to
the list [2, 0, 1], but has a different length.
> [[BR]]
May I ask where in the function it is used that two lists are equivalent
when they only differ by the number of trailing zeroes ?
If it is only when `min_length<max_length`, could you add this mention as
a note in the documentation of `n` (input block)?
> > {{{
> > sage: IntegerListsLex(min_n=4)
> > Integer lists of sum between 4 and 0 satisfying certain constraints
> > sage: list(IntegerListsLex(min_n=4))
> > []
> > }}}
> >
> > Should they really be considered as 'constraints', if the code
accepts them
> > and returns sensible output (i.e. empty sets)? When I read those
lines, I
> > expected the code to raise a `ValueError` exception on them.
>
> The results from the algorithm should be mathematically correct if an
error isn't raised--in this case, the set of such lists is empty, as
advertised. While I was working through the initialization code
yesterday, I did notice that it would be reasonable to include as few
constraints on the initialization as possible and just give an empty
output when conditions are contradictory, but I didn't have time to ensure
that the algorithm was sound under arbitrary permutations of bad
constraints.
Oh, the current behaviour is fine for me! If unsatisfiable parameters lead
to an empty set there is no reason to complain: I was merely saying that
the documentation made it sound like it was 'bad' to create such objects.
Thus, I expected an exception. But if they are handled correctly, why is
it even mentionned in the doc? Empty sets will be returned and so
everything is fine, isn't it?
> Also updated. The waiver parameter is meant to be user-facing; it's
purpose is to suppress a warning raised when the input parameters can't be
checked computationally for cases that don't hang. This situation can
occur when the user specifies an arbitrary function for the floor and
ceiling parameters, so the purpose here is to verify that the user has
thought carefully about what they are asking the algorithm to compute.
I wonder about that... Instead of letting the code hang, wouldn't it be
better to first "explore a bit the floor/ceiling parameters" ? If you see
that up to 10^10 all the values of ceiling do not sum to n, then say that
something is wrong straight away?
> This is mostly an internal marker, and just keeps track of whether we
are in a potentially
> hanging use case (custom user function) that requires a warning to the
user. I've
> changed it to {{{self._warning}}} to indicate that it's an internal
marker, and made
> the comment more verbose for the curious.
Thanks,
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/17979#comment:82>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
