|
Boost : |
Subject: Re: [boost] Algebraic abstractions related to (big) integers in C++
From: pavel (paul.cpprules_at_[hidden])
Date: 2011-03-27 07:44:18
honestly i didn't get the _whole_ point of this message but i have
some comments on it
Thomas wrote on Sunday, March 27, 2011 at 3:21:04:
> ...However, XInt and other bigint libraries
> took the opposite decision, so there is strong circumstantial
> evidence against using two's complement representation for (iii)...
i wondered myself why chad didn't use two's complement because it
seemed straightforward to me but i didn't ever mentioned it
eventually chad stated that sign-magnituted implementation suits
better for non-trivial operations and i have no point to protest
> ...So I tried to write the Quaternion group (the one
> with the 8 elements 1, -1, i, -i, j, -j, k, -k) as a semi-direct
> product. This didn't work, because the Quaternion group is not a
> semi-direct product...
perhaps you ment octonions since quaternions have {1, i, j, k}
elements in contrast to what you mentioned
> ...This is also one
> of the reasons why the two's complement representation should be
> avoided for floating point numbers, because the relevant metric in
> this case is the normal metric of the real numbers.
afaik IEEE 754 / ISO/IEC 60559 standards describe just that
sign-magnitude representation which is widely used in the majority of
computer processors
what i understood is that you suggest to carefully think of
signed/unsigned behavior of integers when one develops an integer
algebra library
but i think that in C++ we have no choice but to follow the
historical tradition and to treat integers like our parents did
otherwise, such way may introduce confusion to users and render well
known idioms unappliable
however i do not object to begin treating integers in semantically
more correct way even if it can cause consequences
-- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk