#19895: extend lazy lists: various improvements and generalizations, new
sublists
-------------------------------------+-------------------------------------
Reporter: dkrenn | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-7.0
Component: misc | Resolution:
Keywords: | Merged in:
Authors: Daniel Krenn | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dkrenn/extend_lazy_lists | 3b63c4792714b2e57dda38b6d9a69e2cf663ba94
Dependencies: #16137 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by dkrenn):
Hello Vincent,
Replying to [comment:8 vdelecroix]:
> This does not look like an improvement to me.
Not so good ;) So we need to discuss...
> Lazy lists aimed to be '''simple'''.
Ok. What exactly does simple mean for you? I ask, because it makes
difference if simple means only a few methods and little code or something
else. What I think: lazy lists are meant as flexible data structures to be
used in various other classes (words, sequences, species, lazy power
series, ...). Thus there should be some flexibility and freedom.
> You are introducing nine new attributes. If you want a `fancy_list`,
just inherit.
I am afraid it is not that easy. The new attributes for formatting should
provide a way to easily change the appearence of the representation
string, e.g. for words (no idea if there is a plan to use this) this could
be `word: 10111010100...`. Concerning sequences: the existing
`Sequence`-class for finite sequences offers a way to add a newline after
each comma in the formatting; this should be possible with the
`HomogenousSequences`, which are in fact lazy lists, as well. Special
sequences (and words as well) might have a name: `fibonacci sequence: 0,
1, 1, 2, 3, 5, ...`.
However, I can think of alternative ways to implement these formatting
features. What comes in my mind right now would be a formatting function,
to which these attributes can be passed. Thus they don't have to be stored
in the class, and one can change them by overriding `_repr_`, but still
get the advantage of not needing to write the full similar code every
time. What is left of these formatting attributes in the class would be
the `name` attribute only.
Since I want to do slicing in inherted classes correctly (i.e. a slice of
a `HomogenousSequence` should again be a `HomogenousSequence` and not a
plain `lazy_list_generic`) the attributes `cls` with the corresponding
keywords are needed.
Concerning a class `fancy_list`: I do not see a point of having another
class, which has the same technical functionality as `lazy_list_generic`,
but only offers more possibilites to work with (like if needed changes its
appearance).
> On the other hand, you can make only one object for
`dropwhile/takewhile`.
What is the disadvantage of having two classes? One class per Feature (and
those two are distinct features, although their name does not reflect
this) is usually a good design choice.
> It is not good to multiply the number of classes in this file. I am
already not happy that we have 4.
Can you tell me why you are unhappy with 4 classes? I just see the
advantage that separate features are into separate classes, which makes
the code better read and understandable. (Indeed I needed a lot of time
understanding the current generic class, which can track a master lazy
list, do slicing and all the other basic stuff at once; however, I am now
good with this design choice)
> I am also not happy with the fact that `start` might change. Could you
make this computation in the constructor of `dropwhile` and avoid
complicating the code of the generic list?
`stop` is already allowed to change, so why should `start` be not allowed
to change? Indeed I thought about doing the computations in the
constructor, but I believe this is not a desired feature. Because then
something already happens, even if no element is accessed. The main
advantage of having the iterator-like lazy lists is that elements are
considered only if needed and not before.
> What is the usecase of `dropwhile/takewhile` that would not be taken
care with `itertools.dropwhile` or `itertools.takewhile`?
Sharing caches (and other information). As I understand that's one of the
main points of having lazy lists.
Looking forward to your answers/comments.
Best, Daniel
--
Ticket URL: <http://trac.sagemath.org/ticket/19895#comment:9>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
