Implement conversions from and to standard IEEE 754 quadruple values about quadruple HOT 5 CLOSED

Like BigDecimal, Quadruple has a set of constructors with different types of arguments, Quadruple(long lv), Quadruple(BigDecimal bd), etc., to create new instances with the given values. Like BigDecimal, it has methods longValue(), doubleValue() etc. (and toString(), of course) to convert its value to other types. Unlike BigDecimal, it's mutable and thus has to have methods to assign new values to instances. I found assign() most natural name for these methods. This way, for every type Quadruple has a pair of methods -- e.g. q = new Quadruple(1.23d); and q.assign(1.23d).
The low-level number presentations are somewhat out of this logic. Double, for example, does not have a constructor for creating an instance made of its physical representation (which is long, in essence), instead it has methods longBitsToDouble(long l) (https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#longBitsToDouble-long-) and doubleToLongBits(double d). Quadruple has a constructor and an assign() method for a set of separate values of the sign, the exponent, the most significant 64 bits of the mantissa, and the least significant 64 bits.
But the IEEE-754 quadruples, in my opinion, is a rather different case. Java has no means to work with them directly, and it has no means to know where is the exponent there, where is mantissa etc. It can only obtain their low-level presentation, or a 'raw' form (that is just 128 bits, from the Java's point of view) from an external source, like a file or a web-service, as a sequence of 16 bytes or a pair of unsigned longs.
It would be just the responsibility of the proposed methods to be aware of the anatomy of the IEEE-754 quadruples, and to provide a capability of importing them, dealing with them in some way, and exporting them back to their raw form (a pair of longs, for example). I would not like to call the assignment method assign (), because then it could be easily confused with the assign () method, which takes an array of long values (https://m-vokhm.github.io/Quadruple/doc/com/mvohm/quadruple/Quadruple.html#assign-long:A-)
By hiPart and loPart I meant unsigned longs containing the most significant 64 bits of the 'raw' form of an IEEE-754 quadruple and the least significant 64 bits, respectively. Yes, they are poor names, so I will be grateful if you propose better ones. A name like theMostSignificant64BitsOfTheRawFormOfAStandardIeee754Quadruple does not seem very good to me, either :)

from quadruple.

The conventions I see most often for similar method signatures is:
from______
and
as______.

However, Java (e.g. BigInteger) tends not to use static "factory" methods for construction (from______), but overloads constructors instead, and then uses to_______ (e.g. toString) to convert to other types, so perhaps that's a better pattern to follow, to stick to the Java API convention.

I would also recommend to stick to the camelCase convention more strictly throughout the codebase, even when it comes to acronyms, e.g. fromIeee745( long hiPart, long loPart). Please see the discussion here. There is always a trade-off
between readability and the standard human language convention, which has spaces to separate IEEE from other words, with consistency in the camelCase convention. This is a pedantic point, however, and might not need much consideration.

More important are descriptive method and parameter names. I'm not able to glean what hiPart and loPart mean without knowing more context, but perhaps if I knew more about how the method worked, the names hiPart and loPart would make sense. Right now I'm guessing they refer to higher- and lower- order portions of the number, but I'm not sure how these can be converted to a floating point number without the sign, exponent, and mantissa parts.

from quadruple.

I think your reasoning about all this is sound, and I concur about .assign____ being the most natural way to modify the existing Quadruple. hiPart and loPart sound pretty good based on what you described, so long as the block comment captures their full meaining, something like "@param hiPart the most significant 64 bits of the IEEE-754 quadruple", etc.

from quadruple.

Ok. Anyway, there is time to think about the names while I work on the documentation.

from quadruple.

Added methods
public Quadruple assignIeee754(long[] value)
public Quadruple assignIeee754(byte[] value)
public long[] toIeee754Longs()
public byte[] toIeee754Bytes()

from quadruple.