#19337: Improve asteroidal triples code
-------------------------------------+-------------------------------------
Reporter: dcoudert | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.9
Component: graph theory | Resolution:
Keywords: | Merged in:
Authors: David Coudert | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dcoudert/asteroid | e32015d13649c7df56362fc9fd2b57937f465705
Dependencies: #19334 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by vbraun):
If you need only 16 bits then there is of course `int_fast16_t`. Its
definition is analogous to plain `int` except that the latter has no
promise of being a particularly fast choice. I don't care about the actual
bitwidth, it should just be reflected (and easily readable) in the code.
Replying to [comment:14 jdemeyer]:
> If you don't want `int`, I'd go with `long` then which is also
guaranteed to be at least 32 bits
But not guaranteed to be particularly fast.
> and which matches the actual return type of
`bitset_first_in_complement()`.
I.e. the "legacy libraries" case.
> > you should never use the old `int` / `long` except to match legacy
libraries, its bad style and very hard to write 100% standards-compliant
code.
> Really, why that? I would say that you should always use types like
`long` unless you need a specific bit-length.
But by using `long` you are already asking for a particular bit width,
except that it does not document the intent (how many Sage contributors
know the specs for `long`?). Usually, you see `long` because
* the author mistakenly believes that it is the longest int type
* the author mistakenly believes that it can hold a pointer
* the author mistakenly believes that it is at least 32-bit
* the author mistakenly believes that it is 64-bit on a 64-bit machine
* cargo cult, i.e., to match legacy code
With the C99 data types you just need to answer
* what is the minimum bit-width required
* do I need to optimize for space or speed
and the resulting program inherently documents it. Its so much better, a
total slam-dunk.
--
Ticket URL: <http://trac.sagemath.org/ticket/19337#comment:20>
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.
