Working with Large Values (double)

[Mike Copeland]

How can I express a large value as a double? (e.g. 1000000.3)
Whereas this compiles and executes, when I try to convert it to a
string value it converts as a scientific string (e.g. "1e+006", not
"1000000.3"). I want to process all the characters of the value of the
data as a std::string.
Or is there a way to convert the double to assure it's not expressed
in scientific notation? TIA

 

[Mike Copeland]

Doubles are floating point and are inherently "in" scientific
notation.

But if you've converted a double to a character format, you can
usually specify a precision, if the default (commonly 6) is not what
you want. With streams, for example, you can use std::setprecision().

Yes, a combination of fixed, setw and setprecision do what I want:

double inVal = 10000000.3;
ostringstream ossw;
ossw.str(""), ossw << fixed << setw(10) << setprecision(2) << inVal
<< ends;
str = ossw.str();

Thanks!

 

[jacob navia]

Le 21/02/2014 06:33, Paavo Helde a écrit :

(e-mail address removed) (Mike Copeland) wrote in


Yes, there are several ways to achieve that. Example:

#include <iostream>
#include <sstream>
#include <iomanip>

int main() {
double x = 10000.3e+34;

std:stringstream oss;
oss << std::fixed << std::setprecision(100) << x;
std::string s = oss.str();

std::cout << s << "\n";
}

This prints:
"100003000000000000000000000000000000000.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

hth
Paavo

Sorry but compiling with gcc gives
100002999999999994323893219714356215808.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Which compiler did you use?

 

[Victor Bazarov]

Le 21/02/2014 06:33, Paavo Helde a écrit :

Sorry but compiling with gcc gives
100002999999999994323893219714356215808.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


Which compiler did you use?

*I* get the crisp "3000" with VC++ 2013 Express, for instance. Not sure
about Paavo, of course.

V

 

[Geoff]

Microsoft VS2012 Professional, 64-bit mode.

I guess both compilers produce correct output. I like gcc behavior more,
it shows better what one can get when blindly following a whim like "I
don't like scientific notation".

Copeland is writing a check writing program, I think scientific
notation might not work in that case.

 

[Mike Copeland]

Doubles are floating point and are inherently "in" scientific

Yes, a combination of fixed, setw and setprecision do what I want:
double inVal = 10000000.3;
ostringstream ossw;
ossw.str(""), ossw << fixed << setw(10) << setprecision(2) << inVal;
str = ossw.str();

Actually, the "setw(10)" isn't needed.

 

[jacob navia]

Le 22/02/2014 02:28, Robert Wessel a écrit :

Attempting to use FP to represent currency is fundamentally doomed to
failure. I didn't see that that's what the OP was doing, but if it
is, he should definitely reconsider, unless he doesn't actually care
about the actual results (which may well be the case if this something
like a homework assignment).

Writing a check of 10000.3e+34 dollars???????????

WOW, I think that goes even beyond the U.S. TOTAL debt!

 

[James Kanze]

Attempting to use FP to represent currency is fundamentally doomed to
failure.

That depends on what you are doing. If you're doing
risk analysis on futures contracts, for example, it's
perfectly appropriate (and you probably can't afford
the loss of performance a decimal solution would cost
you). After all, any rounding errors will be much
less than the variance of the Monte Carlo simulation
anyway.

If you're doing anything even closely related to
legally required bookkeeping, however (and I would
imagine writing checks comes into that providence),
then using machine floating point is probably illegal,
and could, in many jurisdictions, send you to jail.

Note that I say "machine floating point", and not just
FP. There's no problem with a well written decimal
floating point package here. For that matter, it's
possible to use machine floating point, *if* you scale
so that all actual values are exactly representable
whole numbers, and take the proper precautions. It's
anything but trivial, however, and I'd probably go
with a decimal package, even if I had to write it
myself, as being a lot simpler.

 

[James Kanze]

Doubles are floating point and are inherently "in" scientific
notation.

No. Scientific notation, like pratically all other text
formats, is base 10. None of the floating point formats I know
of that are in use today are base 10. And the way machine
floating point typically represents the exponent is not
scientific notation either.

But if you've converted a double to a character format, you can
usually specify a precision, if the default (commonly 6) is not what
you want. With streams, for example, you can use std::setprecision().

Or just call `precision` on the stream itself. (I don't think
I've ever `std::setprecision()`.)

 

[James Kanze]

man 3 snprintf

(Yes, it works fine in C++)

Funny, because it never worked "fine" in C. In C, you use it,
because there's not really anything else, but C formatted output
has to be one of the worst designs ever.

 

[Stefan Ram]

No. Scientific notation, like pratically all other text
formats, is base 10. None of the floating point formats I know
of that are in use today are base 10. And the way machine

It seems the Windows GUI calculator programm uses base 10
(as other pocket calculators?), and also java.math.BigDecimal
uses base 10. C# has a decimal type: »decimal myMoney=300.5m;«.
C++ now has custom literals, so we might be able to copy this.
Maybe Mathematica / Wolfram Alpha uses decimal too.

 

[jacob navia]

Le 23/02/2014 14:59, James Kanze a écrit :

Funny, because it never worked "fine" in C. In C, you use it,
because there's not really anything else, but C formatted output
has to be one of the worst designs ever.

Of course. For instance in the evil C language you use:

printf("0x%08x\n", x);

In the much more advanced C++ language you use:

std::cout << std::hex << std::setfill('0') << std::setw(8) << x <<
std::dec << std::endl;

Of course C has ONE of the worst designs. But C++ has THE WORST!



jacob

 

[woodbrian77]

Le 23/02/2014 14:59, James Kanze a écrit :







Of course. For instance in the evil C language you use:

printf("0x%08x\n", x);

In the much more advanced C++ language you use:

std::cout << std::hex << std::setfill('0') << std::setw(8) << x <<

std::dec << std::endl;

Of course C has ONE of the worst designs. But C++ has THE WORST!

We've discussed this a hundred times. They both have
weaknesses. The poor performance of iostream implementations
is on my list as far as the C++ weaknesses.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

 

[Stefan Ram]

Just as an example of that, assume you have in one file
typedef int Integral;

#include <iostream>
struct integer{ int value; void print(); };
void integer:rint(){ ::std::cout << value; }
int main(){ integer i ={ 2 }; i.print(); }

#include <stdio.h>
struct integer
{ int value; void( * print )( struct integer * this ); };
void print( struct integer * this ){ printf( "%d", this->value ); }
int main(){ struct integer i ={ 2, print }; i.print( &i ); }

 

[Stefan Ram]

Supersedes: <[email protected]>

Just as an example of that, assume you have in one file
typedef int Integral;

#include <iostream>
struct integer{ int value; void print(); };
void integer:rint(){ ::std::cout << value; }
int main(){ integer i ={ 2 }; i.print(); }

#include <stdio.h>
struct integer{ int value; void( * print )( struct integer * ); };
void print( struct integer * this ){ printf( "%d", this->value ); }
int main(){ struct integer i ={ 2, print }; i.print( &i ); }

 

[Gerhard Fiedler]

Le 23/02/2014 14:59, James Kanze a écrit :

Of course. For instance in the evil C language you use:

printf("0x%08x\n", x);

In the much more advanced C++ language you use:

std::cout << std::hex << std::setfill('0') << std::setw(8) << x <<
std::dec << std::endl;

If you have a need to print this more often than once, then there are
other language features that you can use to encapsulate all this.

There are also libraries that use C++ features to provide something
similar in ways that avoid some of the problems of built-in streams.

OTOH, (type-safely) encapsulating printf is quite the challenge.

Gerhard

 

[Stefan Ram]

There are also libraries that use C++ features to provide something
similar in ways that avoid some of the problems of built-in streams.

You both sound a little bit as if it were not possible to use
printf in C++.

OTOH, (type-safely) encapsulating printf is quite the challenge.

Sometimes, language support for OOP or generic programming is better.
I don't think anyone would deny this.

But sometimes, printf is more readable and writeable. That's why, in
2004, they have added printf to the Java programming language after
Java already had formatted printing right from the start in 1995, but
using a call-style interface instead of a DSL like printf.

 

[jacob navia]

Le 24/02/2014 12:32, Juha Nieminen a écrit :

The C version is not type safe

Most modern C compilers will warn if you pass an incorrect type to
printf. please, no straw men here.

 

[jacob navia]

Le 24/02/2014 12:32, Juha Nieminen a écrit :

The C version is not type safe, cannot be expanded with new types,

In C++ you have to overload the operator << as far as I remember. In C
you have to write a "Print_XXX" function. I do not see why C++ is so
fundamentally better.

But I am afraid you will never be convinced (of course). Do as you wish,
but stop denigrating other computer languages that can be used as
effectively as C++.

Since its birth, C++ tried to be the "better C", "C with classes"
whatever. That is why it is fundamental for them to denigrate C to
convince everyone that C++ is the "better way".

Maybe you would stop doing that?

After 20 years of insults and lies, you have won. You have destroyed the
C language to the point that the C standards committee doesn't dare to
prescrive something for fear it would bother the C++ language, or make a
comptetition with C++. Thus, C has stagnated, nothing is being developed
and all efforts go to C++.

Look, now you have anonymous lambdas and all common lisp in your language.

Why go on pounding C?

Is it not enough already?

When I try to discuss a package I wrote ( a C containers library) in
comp.lang.c hordes of C++ people go there to "preach the good word" and
tell me that what I did (and run every day) is "impossible, I am lying C
can't do that" etc.

Just stop denigrating C.

Thanks in advance

jacob

 

[Stefan Ram]

Le 24/02/2014 12:32, Juha Nieminen a écrit :
In C++ you have to overload the operator << as far as I remember. In C
you have to write a "Print_XXX" function. I do not see why C++ is so
fundamentally better.

Because in C++, the user can always use the same verb:

.... << x ...
.... << i ...

while in C, he has to remember individual verbs per type

print_double( x )
print_int( x )

or cannot infer a static type at all, because the type is
not know at compile time, in which case one needs to start
to implement OO in C, which is already supplied by the
language in C++.