2011/4/10 James K Beard :
> JonY - well, mine is in Fortran 95 structured format, with layers of classes
> and derived data types. An experienced programmer could port it to C++
> fairly quickly, giving you a a C++ class with overloaded arithmetic and
> casting/data conversion operations. But I'm
That epsilon will fit in quad precision.
James K Beard
-Original Message-
From: Jon [mailto:10wa...@gmail.com] On Behalf Of JonY
Sent: Saturday, April 09, 2011 9:07 PM
To: jkbea...@verizon.net; mingw-w64-public@lists.sourceforge.net
Cc: James K Beard
Subject: Re: [Mingw-w64-public] mingw
JonY - well, mine is in Fortran 95 structured format, with layers of classes
and derived data types. An experienced programmer could port it to C++
fairly quickly, giving you a a C++ class with overloaded arithmetic and
casting/data conversion operations. But I'm not a C++ programmer and don't
wa
Basically, if you make the base 10 arithmetic work for its only real user
base - financial applications - there is no problem in base 10 I/O and
binary in the innards, and that's the way it's been done since the early
1960's or so. If you want to impose drastic word length and overflow
requirement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/10/2011 01:54, James K Beard wrote:
> I think the long term solution is to implement the decimal arithmetic
> keywords with an open mind. Special requirements, like extremely long
> decimal words (DECIMAL128 == 128 digits?) may require multip
> Hi,
>
> Sorry for jumping into this discussion, but I don't seem to understand what
> the advantage is of a non-hardware supported real number representation. If
> you need the two (or a bit more) decimal places required for currency and
> percentages, why not just use a big integer and for displ
I think the long term solution is to implement the decimal arithmetic
keywords with an open mind. Special requirements, like extremely long
decimal words (DECIMAL128 == 128 digits?) may require multiple-precision
arithmetic, which may be problematic because most compilers support up to
quad pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/9/2011 23:03, K. Frank wrote:
>
> What, then, would be the advantage of using decimal floating-point?
> I don't really know the history or what people were thinking when
> they built those early decimal floating-point systems, but there is
> a (m
Keith: No, COBOL is just another computer language. Early on, most
computer users were business users, and decimal I/O is standard for all
internationally accepted currencies. Some early computers, like the 8-bit
VAX (remember the 11/78??? The CDC 3100 series?) actually had decimal
arithmetic ha
Hi Jon and Ruben!
On Sat, Apr 9, 2011 at 9:47 AM, JonY wrote:
> ...
> On 4/9/2011 21:33, Ruben Van Boxem wrote:
>> Hi,
>>
>> Sorry for jumping into this discussion, but I don't seem to understand what
>> the advantage is of a non-hardware supported real number representation. If
>> you need the t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/9/2011 21:33, Ruben Van Boxem wrote:
> Hi,
>
> Sorry for jumping into this discussion, but I don't seem to understand what
> the advantage is of a non-hardware supported real number representation. If
> you need the two (or a bit more) decimal pl
Hi,
Sorry for jumping into this discussion, but I don't seem to understand what
the advantage is of a non-hardware supported real number representation. If
you need the two (or a bit more) decimal places required for currency and
percentages, why not just use a big integer and for display divide b
Hello NightStrike!
On Sat, Apr 9, 2011 at 2:41 AM, NightStrike wrote:
> On Sun, Apr 3, 2011 at 7:07 AM, James K Beard wrote:
>> A quick glance through the document seems to tell us that the decimal
>> arithmetic will incorporate checks to ensure that any rounding in binary
>> floating point does
2011/4/9 NightStrike
>
> I'm being a little OT here, but I'm curious.. does that mean that
> COBOL was a language that gave very high accuracy compared to C of the
> day?
>
>
Cobol is quite anterior to C. It is not so much that it has high accuracy as
it avoids decimal to binary and binary to dec
the point is, I shouldn't have to modify the code. it should be done with
compiler switches.
unless your method of "packing" is compiler independent.
the compiler shouldn't balk when I throw the -fpack-struct switch.so why
did
they even make the switch if it's not going to work?
actually,
15 matches
Mail list logo