2009-07-08 29 views
10

En primer lugar debo preguntar:
¿Alguien sabe de un UINT 128b implementación actual para Java?Java: La implementación de un número entero de 128 bits sin signo

Necesito algo para mantener los valores cardinales naturales. es decir: un gran contador.
Conozco BigIntegers, que son lentos e inmutables. Un UINT 128b tiene sentido ...

Estaba pensando en implementar un OWORD, usando un par de longs primitivos.

Los desbordamientos arrojarían una excepción y no quedarían en blanco.

¿Qué código fuente/blogs de ejemplo debo considerar para implementar el funcionamiento de esta clase?

+0

Implementado algo similar hace un año, y todo lo que puedo decir es: Espero que no tengas que implementar módulo/división preciso ...;) – Tim

+2

Podrías tomar MutableBigInteger de OpenJDK http://www.docjar.org /html/api/java/math/MutableBigInteger.java.html – akarnokd

Respuesta

0

¿Por qué no utilizar BigInteger?

+10

BigInteger es _slow_ cuando todo lo que necesita es solo un poco más de 64 bits ... Se encontró con este problema hace un año y resultó ser 25 veces más lento que el original. . Consulte esta información para obtener más detalles: http://stackoverflow.com/questions/962747/most-shameful-awesome-language-hack/1084538#1084538 – Tim

+9

Es extraño que esta sea la respuesta aceptada, teniendo en cuenta que OP dijo que no quería BigInteger . –

+4

Tim, su comentario contiene un enlace roto. – Gili

4

Usaría números enteros de 32 bits como la representación, porque necesita un tipo más grande (largo) para obtener la precisión adicional para el bit de acarreo, la detección de desbordamiento y la multiplicación. Piense en un entero de 32 bits como un dígito y aplique los algoritmos de la escuela primaria.

+1

Puede usar longitudes de 64 bits muy bien ==> el doble de rápido. Una ejecución se puede determinar mediante cambios en el bit de signo. –

+0

@Ira Baxter Dudo que sea más rápido. Sería posible pero más complicado para la suma, pero no para la multiplicación. Java BigInteger usa int [], y supongo que ellos saben lo que están haciendo. – starblue

+0

Si desea un paquete BigInt de muy alto rendimiento, use el tamaño de palabras más grande disponible para su máquina para el cual hay soporte nativo de instrucción de máquina. Es difícil encontrar una PC en estos días que no sea de 64 bits. Mantengo mi posición: usa un largo. Los algoritmos en el paquete BigInt son probablemente típicos de la mayoría de los paquetes de multiprecision; long debería caer con relativa facilidad en su lugar. Las adiciones de bigints grandes ahora simplemente toman la mitad de tantos ciclos. Las multiplicaciones deben ser 4 veces más rápidas porque solo necesita 1 producto en lugar de 4 productos cruzados de la mitad de ancho. –

3

No me diga que planea tener 128 ajustadores estáticos y getters, uno para cada bit ??? Definitivamente iría por setBit (int index, boolean value) y getBit (int index) como métodos de instancia.

Más cosas que necesita: un método toString() para que pueda obtener una representación legible (en algún momento querrá imprimir los números, creo).

Recuerde que todos los tipos ordinales en java están firmados (con la excepción de caracteres), por lo tanto, si planea usar dos largos, tenga siempre en cuenta que la parte inferior podría ser problemática para detectar desbordamientos y ... de todos modos, tendrá un número de 127 bits a menos que la parte inferior se trate como un bit 63 sin signo.

+0

¿Dónde el OP incluso sugirió a los setters para cada bit? –

+0

http://stackoverflow.com/revisions/1096964/list debe echar un vistazo antes de criticar. – fortran

+1

OK, ahora lo veo. No esperaba que tuviera que leer las revisiones de una pregunta para entenderla; eso parece un poco exagerado He anulado tu respuesta. –

Cuestiones relacionadas