#9798: Accelerate Polyhedron constructor and fix cddlib output ordering
----------------------------+-----------------------------------------------
Reporter: vbraun | Owner: mhampton
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.6
Component: geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
----------------------------+-----------------------------------------------
Comment(by drkirkby):
FWIW, I can see that using GSL in Sage is sensible, since we have it.
But whether such changes would be accepted upstream is another matter. If
I maintained a bit of software that just needed a low-quality source of
random numbers, I'd probably implement something like
{{{
X_n= seed
X_n+1 = ( (X_n * A) + B ) mod C
}}}
If you make sure that this can't overflow the type of variable (e.g. long)
then there's no hardware dependence. The reason such RNG's can have
hardware dependence is when they overflow the register.
I would not want people to have to install GSL just to get a few random
numbers.
I can't see why a simple low-quality RNG should take up 4 KB - I could
write it in a few hundred bytes. It would help if people attached patches
to the ticket, so others can see what changes you have made.
If the RNG I showed is not good enough, then there's a bit more of an
argument for making GSL a dependence upstream.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9798#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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
