It may not be as bad as you might think because trigonometric functions
become invalid for arguments with magnitude defined by the mantissa length,
not the exponent, and the exponent is removed as part of the process in log
and exponentiation operations.
James K Beard
-Original Message-
F
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/24/2011 02:29, Kai Tietz wrote:
> 2011/3/23 James K Beard :
>> You don't need to go to BCD to convert DFP to IEEE (regular) floating point.
>> A single arithmetic operation directly in DFP will exceed what you do to
>> convert to IEEE floating poi
Hello James!
On Wed, Mar 23, 2011 at 4:45 PM, James K Beard wrote:
> Excuse me, but isn't the representation of a number in BCD unique except for
> some esoteric special cases?
Well, we could quibble about some specific details, but for the sake
of this discussion, yes, let's take the BCD repres
Excuse me, but isn't the representation of a number in BCD unique except for
some esoteric special cases? Why wouldn't the conversion of a binary
floating point result give a correct result when converted to BCD? Perhaps
I'm being naïve here so please help me out here.
BCD arithmetic - but not t
You need to go with the guard bits, which is the excess in the number of
bits in the IEEE double precision mantissa (52, or 15.65 decimal places for
64-bit, ) and the 20.47 in 80-bit). All common arithmetic co-processors
operate with 80-bit floating point with a 12-bit exponent, thus have 16
guard
Hi Jon and James!
On Wed, Mar 23, 2011 at 12:45 PM, JonY wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 3/23/2011 22:06, James K Beard wrote:
>> Jon: The simplest and quite possibly the most efficient way to implement a
>> standard function library in BCD decimal arithmetic is t
2011/3/23 James K Beard :
> You don't need to go to BCD to convert DFP to IEEE (regular) floating point.
> A single arithmetic operation directly in DFP will exceed what you do to
> convert to IEEE floating point. I would use double precision for anything
> up to 12 decimals of accuracy, 80-bit fo
You don't need to go to BCD to convert DFP to IEEE (regular) floating point.
A single arithmetic operation directly in DFP will exceed what you do to
convert to IEEE floating point. I would use double precision for anything
up to 12 decimals of accuracy, 80-bit for another three, and simply
incorp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 22:06, James K Beard wrote:
> Jon: The simplest and quite possibly the most efficient way to implement a
> standard function library in BCD decimal arithmetic is to convert to IEEE
> standard double precision (or, if necessary, quad preci
For broadest compatibility I suggest C99 standard, #include and
ull or ll as the Plan A, and if your compiler doesn't work with that humor
it with an ifdef. The C99 standard works for me for the Linux hosted
cross-compilers.
James K Beard
From: Jim Michaels [mailto:jmich...@yahoo.com]
Se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I'm working on DFP math for mingw-w64, the main hurdle is that the
mathematical values should never be converted to conventional floating
point.
Dr Beard,
I'm hoping you can help me out on this task in the future.
I have some documentation o
2011/3/23 NightStrike :
> On Tue, Mar 22, 2011 at 2:57 PM, Vincent Torri
> wrote:
>>
>>
>> On Tue, Mar 22, 2011 at 9:52 AM, Prof Brian Ripley
>> wrote:
>>>
>>> On Mon, 21 Mar 2011, NightStrike wrote:
>>>
On Sun, Mar 20, 2011 at 9:03 PM, Jim Michaels wrote:
>
> I don't know who to g
On Tue, Mar 22, 2011 at 2:57 PM, Vincent Torri wrote:
>
>
> On Tue, Mar 22, 2011 at 9:52 AM, Prof Brian Ripley
> wrote:
>>
>> On Mon, 21 Mar 2011, NightStrike wrote:
>>
>>> On Sun, Mar 20, 2011 at 9:03 PM, Jim Michaels wrote:
I don't know who to go to to make this change request to the
On Wed, Mar 23, 2011 at 8:09 AM, Jim Michaels wrote:
> why does ll not work for int64_t and long long (I think) and __int64?
>
>
> this is quite noticeable. all my programs have to be #ifdef'd.
>
> #if defined(__BORLANDC__)||defined(__MINGW32__)||defined(_MSC_VER)
> printf("%I64d", int64_t(2));
why does ll not work for int64_t and long long (I think) and __int64?
this is quite noticeable. all my programs have to be #ifdef'd.
#if defined(__BORLANDC__)||defined(__MINGW32__)||defined(_MSC_VER)
printf("%I64d", int64_t(2)); //don't try this with ll
#elif defined(__DJGPP__)
printf("%lld", in
15 matches
Mail list logo
