#15820: Implement sequences of bounded integers
-------------------------------------+-------------------------------------
       Reporter:  SimonKing          |        Owner:
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.3
      Component:  algebra            |   Resolution:
       Keywords:  sequence bounded   |    Merged in:
  integer                            |    Reviewers:
        Authors:  Simon King         |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:                     |  5dc78c5f5f647bf95b98da916d7086fae539ffb8
  u/SimonKing/ticket/15820           |     Stopgaps:
   Dependencies:                     |
-------------------------------------+-------------------------------------

Comment (by SimonKing):

 Replying to [comment:52 ncohen]:
 > - bounded integer sequence, biseq. What about "integer sequence" ?

 Not good, because...

 >  All integers are "bounded" on a computer. Why add this "bounded"
 everywhere ? biseq -> iseq

 ... the computer's integer bound is chosen when you buy the machine, but
 not when you create the sequence.

 The point is that each "bounded integer sequence" has a bound `B` that can
 be ''chosen upon initialisation'' so that any item of the sequence is
 smaller than `B`.

 > - `# Bitsize of "data"` --> bitsize of the whole sequence

 OK.

 > - itembitsize --> necessarily a power of 2 ?

 No. Here, it is really "bit" size. So, the number tells how many bits will
 be reserved to store one item. Hence, the bound `B` above is a power of
 two, namely `2^itembitsize`.

 > - `#cdef inline void dealloc_biseq(biseq_t S)` : why there if commented
 ?

 Because I forgot to remove it.

 > - `list2biseq` (and others) -> `list_to_biseq` ?

 Acceptable.

 > - Comments on the function definitions --> Move it to the function's
 doc, even
 >   if it is their only content ?
 > - Could you write some doc, even if it is just one line, for cdef
 functions ?

 I wouldn't remove the comments from the pxd file, but certainly some
 documentation should be added to the cdef functions in the pyx file. I
 wonder if this should be by comments in the code or by a doc string. After
 all, the doc string will not be visible (cdef functions won't appear in
 the docs, as they can not imported).

 > - I just figured out that you may have wanted to keep this list of
 functions
 >   above with short descriptions as an 'index' of what the file does. If
 so, it
 >   would be cool to do it in the html doc instead !

 You mean: "This file provides the following boilerplate functions, that
 you can cimport for usage in Cython code: ..."?

 > - list2biseq --> I wondered why this function wouldn't return a new
 biseq buil
 >   from a list instead of modifying an existing one.... Performance issue
 ? Is
 >   that critical in some cases ?

 This is motivated by my usage in the `BoundedIntegerSequence` wrapper. As
 usual, there is `__cinit__` which does memory allocations (as much as I
 know, it is recommended to not do this kind of things in `__init__`).
 Hence, when `__init__` is called (and I think filling data into the
 allocated memory is the job of `__init__`, not of `__cinit__`), then the
 integer sequence already is allocated, and just needs to be filled.

--
Ticket URL: <http://trac.sagemath.org/ticket/15820#comment:53>
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.

Reply via email to