Complex numbers and printf
jacob navia
Since I am revising the lcc-win implementation of complex numbers
I decided to fill this hole with
"Z"
for instance
double _Complex m = 2+3*I;
printf("%Zg\n",m);
will print
2+3*I
The alternative flag makes this look like:
printf("%#Zg\n",m);
2.00000+3.00000i
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Gerry Ford
"jacob navia" <ja...@nospam.com> wrote in message
news:fq8jj0$oll$1...@aioe.org...
> The C99 standard forgot to define the printf equivalent for complex
> numbers
>
>
> Since I am revising the lcc-win implementation of complex numbers
> I decided to fill this hole with
> "Z"
>
> for instance
> double _Complex m = 2+3*I;
> printf("%Zg\n",m);
> will print
> 2+3*I
>
> The alternative flag makes this look like:
>
> printf("%#Zg\n",m);
> 2.00000+3.00000i
I don't think it's quite like that, Jacob, much like the dinner I ingested
on the Champs d'Elyzee. Unlike those 6 chefs 2 dieners, who knew to feed my
wife excellent cuisine while they fed me a horse's willy that I either gave
to my shirt pocket or to the sidewalk on our way back to the hotel, I
actually expected a meal.
I'd be interested to try a new version of lcc.
--
Gerry Ford
"Er hat sich georgiert." Der Spiegel, 2008, sich auf Chimpy Eins komma null
beziehend.
Doug Miller
>I don't think it's quite like that, Jacob, much like the dinner I ingested
>on the Champs d'Elyzee. Unlike those 6 chefs 2 dieners, who knew to feed my
>wife excellent cuisine while they fed me a horse's willy that I either gave
>to my shirt pocket or to the sidewalk on our way back to the hotel, I
>actually expected a meal.
In future, please sober up before posting. Thank you.
jacob navia
[bad dinner left a lasting impression]
Coming back to complex numbers... Any comments?
Joachim Schmitz
> Gerry Ford wrote:
>
> [bad dinner left a lasting impression]
>
> Coming back to complex numbers... Any comments?
Bye, Jojo
Joachim Schmitz
> Gerry Ford wrote:
>
> [bad dinner left a lasting impression]
>
> Coming back to complex numbers... Any comments?
comments...
jacob navia
No.
I do not think it is necessary since this is an
illegal combination for printf anyway. It WILL give
a warning if you do not pass it a complex number
of course.
jacob navia
Excuse me. I should have request comments more explicitely.
I hope I do not mess something else. I used "Z" since in the lasts
discussions (about my "b" extension) people complained that it was a
lower case letter. Then I used now upper case ones.
Richard Heathfield
No diagnostic message is required for invalid format specifiers to printf.
The behaviour is undefined, and implementations can do anything they like
as a consequence. In lcc-win32, maybe the implementation will treat the
argument as a complex number. Perhaps under some other implementation
it'll format the hard disk. Life gets exciting when you allow your code to
rely on non-standard extensions and then re-compile the code in a
different environment.
I'm not quite sure why this thread is cross-posted to comp.lang.c - it
seems to be an entirely lcc-related subject.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nelu
> The C99 standard forgot to define the printf equivalent for complex
> numbers
>
>
> Since I am revising the lcc-win implementation of complex numbers I
> decided to fill this hole with
> "Z"
>
> for instance
> double _Complex m = 2+3*I;
> printf("%Zg\n",m);
> will print
> 2+3*I
>
> The alternative flag makes this look like:
>
> printf("%#Zg\n",m);
> 2.00000+3.00000i
Is it worth doing this? I mean is there a good reason to make the
programmer remember an extra formatting option that's non standard
instead of allowing him to use what he already knows? I mean doing printf
("%f+%f*I\n",real(m),imag(m)) is not that big of an effort, is it?
However, if you really want to have this formatting option it's probably
a good idea to talk to the guys in comp.std.c and see if they are
considering something like that and whether or not your implementation
may be affected by the standard in the future.
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Nelu
> Gerry Ford wrote:
>
> [bad dinner left a lasting impression]
>
> Coming back to complex numbers... Any comments?
What about complex numbers?
Keith Thompson
> The C99 standard forgot to define the printf equivalent for complex numbers
I doubt that they forgot; they probably just didn't feel it was
necessary. In my opinion, they were right.
> Since I am revising the lcc-win implementation of complex numbers
> I decided to fill this hole with
> "Z"
Do you have a similar extension for scanf?
> for instance
> double _Complex m = 2+3*I;
> printf("%Zg\n",m);
> will print
> 2+3*I
>
> The alternative flag makes this look like:
>
> printf("%#Zg\n",m);
> 2.00000+3.00000i
I see no problem with this extension in terms of conformance to the
standard. Though I don't see any particular need for a special format
for complex numbers, I wouldn't object if such a format were added to
a future version of the standard.
However, if I were a user of lcc-win, I probably wouldn't use it in my
own code, for several reasons.
First, it is of course an extension. Unless my code already depends
on other lcc-win extensions, I'd rather not limit its portability for
the sake of a minor convenience.
Second, it's inflexible; it imposes one of two output representations
for complex numbers. If I want to print "2+3*I", I can write:
printf("%g+%g*I\n", creal(m), cimag(m));
If I want to print "2 + 3i", of course, I can write:
printf("%g + %gi\n", creal(m), cimag(m));
which your extension doesn't support, but the standard already does.
In effect, I tend to think of a complex number as a number (usually)
for purposes of arithmetic, but as a composite structure for purposes
of I/O. Perhaps that's just me.
Finally Fortran has supported complex numbers, and I/O on them, since
dinosaurs walked the Earth. The result of printing 2+3*I in Fortran
would be "(2.,3.)" (at least by default using g77; I don't know
Fortran well enough to know whether that's standard). That form is
also valid in Fortran source as a complex literal (insert previous
disclaimer here).
Note that a parenthesized format might make things easier for a
corresponding scanf extension.
This is not to say that your extension is a bad idea, merely that I
personally don't find it to be a sufficiently good idea to pique my
interest. (And yet here I am writing about it at some length.)
Or, as "Gerry Ford" might put it, "Bertha termite prefecture
psychopomp inhabit dovetail statuette virus superlative deposition."
--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer
>
> The C99 standard forgot to define the printf equivalent for
> complex numbers
I don't believe so. Formatting of such dumps is easily done by
selecting the real and imaginary portions, and using the existing
printf operations to format them. Why standardize something that
will not be used and is unnecessary?
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Walter Roberson
>The C99 standard forgot to define the printf equivalent for complex numbers
>Since I am revising the lcc-win implementation of complex numbers
>I decided to fill this hole with
>"Z"
Historically, Z was usually associated with hexadecimal
(but it has been years since I've seen that.)
--
"To all, to each! a fair good-night,
And pleasing dreams, and slumbers light" -- Sir Walter Scott
lawrenc...@siemens.com
>
> The C99 standard forgot to define the printf equivalent for complex numbers
No it didn't. The committee made a concious decision *not* to define a
format for complex numbers since there is no agreed upon format and it's
easy enough to format the real and imaginary parts yourself however you
desire.
-Larry Jones
I take it there's no qualifying exam to be a Dad. -- Calvin
Walter Roberson
Keith Thompson <ks...@mib.org> wrote:
>Second, it's inflexible; it imposes one of two output representations
>for complex numbers. If I want to print "2+3*I", I can write:
> printf("%g+%g*I\n", creal(m), cimag(m));
>If I want to print "2 + 3i", of course, I can write:
> printf("%g + %gi\n", creal(m), cimag(m));
>which your extension doesn't support, but the standard already does.
Then there is engineering, in which the imaginary constant is
usually represented as 'j' instead of 'i' or 'I'.
--
"Style is instinctive and few achieve it in a notable degree. Its
development is not hastened by instruction. It comes or it doesn't.
It will take care of itself." -- Walter J. Phillips
Nelu
<snip>
> printf ("%f+%f*I\n",real(m),imag(m)) is not that big of an effort, is
That's probably creal and cimag. I think the real/imag forms are only
available in C++.
Walter Roberson
>> The C99 standard forgot to define the printf equivalent for
>> complex numbers
>I don't believe so. Formatting of such dumps is easily done by
>selecting the real and imaginary portions, and using the existing
>printf operations to format them. Why standardize something that
>will not be used and is unnecessary?
Because it gives an opportunity to demonstrate the incomparible
beauty of operator overloading??
jacob navia
> In article <47C824AF...@yahoo.com>,
> CBFalconer <cbfal...@maineline.net> wrote:
>> jacob navia wrote:
>
>>> The C99 standard forgot to define the printf equivalent for
>>> complex numbers
>
>> I don't believe so. Formatting of such dumps is easily done by
>> selecting the real and imaginary portions, and using the existing
>> printf operations to format them. Why standardize something that
>> will not be used and is unnecessary?
>
> Because it gives an opportunity to demonstrate the incomparible
> beauty of operator overloading??
Operator overloading in printf?
Funny how much nonsense you can say. Are you paid by the nonsense line?
Or you do it for free as a hobby?
Bartc
> numbers
>
>
> Since I am revising the lcc-win implementation of complex numbers
> I decided to fill this hole with
> printf("%Zg\n",m);
> 2+3*I
> printf("%#Zg\n",m);
> 2.00000+3.00000i
As has been mentioned, it may not be flexible enough for all situations, but
may be convenient sometimes.
But inventing new printf formats is fun; how about the following for
printing arrays and blocks of data:
int a[] = {10,20,30,40,50,60};
printf(" (%A,%d)\n",a,6);
will print: (10,20,30,40,50,60)
%A means array print, the parameter should point to the data. An extra
int/size_t parameter is how many values to print. The format of each element
follows (%d). The text between %A and %d is separator chars. Maybe %10A for
10 elems per line.
Might get more use than %Z anyway.
--
Bart
Morris Dovey
> But inventing new printf formats is fun; how about the following for
> printing arrays and blocks of data:
>
> int a[] = {10,20,30,40,50,60};
>
> printf(" (%A,%d)\n",a,6);
>
> will print: (10,20,30,40,50,60)
>
> %A means array print, the parameter should point to the data. An extra
> int/size_t parameter is how many values to print. The format of each element
> follows (%d). The text between %A and %d is separator chars. Maybe %10A for
> 10 elems per line.
>
> Might get more use than %Z anyway.
Cool! How about:
printf("%f",a[i=0; i<6; i++]);
--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/Stirling/
Martin Ambuhl
> But inventing new printf formats is fun; how about the following for
> printing arrays and blocks of data:
>
> int a[] = {10,20,30,40,50,60};
>
> printf(" (%A,%d)\n",a,6);
>
> will print: (10,20,30,40,50,60)
>
> %A means array print,
You'll need to choose some other specifier. "%A" already is defined for
signed hexadecimal floating-point conversion.
burton.sa...@am.gmail.com
> Bartc wrote:
> Cool! How about:
>
> printf("%f",a[i=0; i<6; i++]);
Heh, I just had to try that thinking I missed a new feature of C99 ;-)
--
burton
Eric Sosman
> Bartc wrote:
>
>> But inventing new printf formats is fun; how about the following for
>> printing arrays and blocks of data:
>>
>> int a[] = {10,20,30,40,50,60};
>>
>> printf(" (%A,%d)\n",a,6);
>>
>> will print: (10,20,30,40,50,60)
>>
>> %A means array print, the parameter should point to the data. An extra
>> int/size_t parameter is how many values to print. The format of each element
>> follows (%d). The text between %A and %d is separator chars. Maybe %10A for
>> 10 elems per line.
>>
>> Might get more use than %Z anyway.
>
> Cool! How about:
>
> printf("%f",a[i=0; i<6; i++]);
Ahhh, that conjures up memories, that does. It was hard
work shovelling punched cards into the computer's firebox
(steam-powered computers in those days; had to keep up the
pressure if you wanted any accuracy), but back then I was
young, and strong, and stupid in that particular way that
expressed itself in ever more ingenious combinations of WRITE
and FORMAT. Little programming languages embedded inside the
larger one, seeming at times almost Turing-complete.
The old memories fade and blur, but never quite die ...
Morris Dovey
>
> Morris Dovey <mrd...@iedu.com> writes:
>
> > printf("%f ",a[i=0; i<6; i++]);
>
> Heh, I just had to try that thinking I missed a new feature of C99 ;-)
I wish. It was just an "implied DO loop" adapted from FORTRAN IV
(and later) READ/WRITE statements - wishful thinking on my part.
burton.sa...@nopespam.gmail.com
> burton.sa...@AM.gmail.com wrote:
>>
>> Morris Dovey <mrd...@iedu.com> writes:
>>
>> > printf("%f ",a[i=0; i<6; i++]);
>>
>> Heh, I just had to try that thinking I missed a new feature of C99 ;-)
>
> I wish. It was just an "implied DO loop" adapted from FORTRAN IV
> (and later) READ/WRITE statements - wishful thinking on my part.
Wow, that's an interesting syntactic construct for a complied
language. I haven't looked at FORTRAN at all, but that's pretty
interesting that they have that feature. I was looking closer at the
C version you wrote and was wondering if it even could be implemented
in your typical C compiler...
/me goes off to read more about FORTRAN...
--
burton
Walter Roberson
>Walter Roberson wrote:
>> Because it gives an opportunity to demonstrate the incomparible
>> beauty of operator overloading??
>Operator overloading in printf?
Why -not- operator overloading in printf() ? Other than, of course,
the matter of whether printf() qualifies as an "operator"
or not.
Urrr, you do allow operator overloading of varadic functions,
don't you?
>Funny how much nonsense you can say. Are you paid by the nonsense line?
>Or you do it for free as a hobby?
Why, the union contract sets out a monthly quota of course.
--
"Prevention is the daughter of intelligence."
-- Sir Walter Raleigh
Serve Laurijssen
"Walter Roberson" <robe...@ibd.nrc-cnrc.gc.ca> schreef in bericht
news:fq9ftp$t3f$1...@canopus.cc.umanitoba.ca...
> In article <87skzbo...@kvetch.smov.org>,
> Keith Thompson <ks...@mib.org> wrote:
>
>>Second, it's inflexible; it imposes one of two output representations
>>for complex numbers. If I want to print "2+3*I", I can write:
>
>> printf("%g+%g*I\n", creal(m), cimag(m));
>
>>If I want to print "2 + 3i", of course, I can write:
>
>> printf("%g + %gi\n", creal(m), cimag(m));
>
>>which your extension doesn't support, but the standard already does.
>
> Then there is engineering, in which the imaginary constant is
> usually represented as 'j' instead of 'i' or 'I'.
I guess that is why it isnt put in and it wasnt an oversight.
It is interesting to see that in C++ you can output complex numbers with
cout, although I dont know if thats standard.
std::complex<double> c(5., 6.);
std::cout << c << std::endl;
this prints: "(5,6)" on my machine
If thats standard I would say use that same mechanism in lccwin32 too and
also in the C standard if it ever gets adopted. More consistent this way
David Thompson
wrote:
> jacob navia <ja...@nospam.com> writes:
<snip: use modifier Z for complex>
> Second, it's inflexible; it imposes one of two output representations
One of many possible representations.
> for complex numbers. If I want to print "2+3*I", I can write:
>
> printf("%g+%g*I\n", creal(m), cimag(m));
>
> If I want to print "2 + 3i", of course, I can write:
>
> printf("%g + %gi\n", creal(m), cimag(m));
>
> which your extension doesn't support, but the standard already does.
>
> In effect, I tend to think of a complex number as a number (usually)
> for purposes of arithmetic, but as a composite structure for purposes
> of I/O. Perhaps that's just me.
>
> Finally Fortran has supported complex numbers, and I/O on them, since
> dinosaurs walked the Earth. The result of printing 2+3*I in Fortran
> would be "(2.,3.)" (at least by default using g77; I don't know
> Fortran well enough to know whether that's standard). That form is
> also valid in Fortran source as a complex literal (insert previous
> disclaimer here).
>
More specifically _list-directed_ output does that, and is standard
since at least F77 (see below). For small values such as your example;
for values outside an implementation-dependent range it will switch to
E-style instead of F-style, much like Fortran G or C printf %g
switches for a real (noncomplex) float. And yes, that list-directed
(and namelist) output and input syntax is I believe deliberately the
same as for a literal in source, much as C scanf %i or strtol(,,0)
accepts 0octal and 0xhex (plus sign). <OT>(And inetaddr!)</>
I _think_ list (and namelist) was new in F77, but since at least
FIV=66 Fortran has had explicitly-formatted output and input of
COMPLEX treated as a series of two REALs, in the same way it treats an
array (or in F90+ an array section) as its elements in order. (And
F90+ treats a struct-like TYPE as its components in order, unless in
F03 you provide a user-defined routine.) Fortran does and did allow
any data format descriptor (or parenthesized part of a format) to have
a repeat count, so a single descriptor like 2F8.3 can handle both
parts of a COMPLEX if you want NO punctuation, in the same way say
99I5 can handle an array of 99 (or less) INTEGERs.
This is more like the C99 approach except for the convenience of not
writing out 'realpart' and 'imagpart' selectors. Or rather, we could
say C99 printf follows the practice (long) established by Fortran as
closely as its function-call-by-value (vs statement) easily allows.
- formerly david.thompson1 || achar(64) || worldnet.att.net
Gerry Ford
"David Thompson" <dave.th...@verizon.net> wrote in message
news:v7m8t397ab2erfc02...@4ax.com...
Nuts, Sr. Thompson.
I usually read your posts as a bellweather to syntax.
Fortran and printf: don't do it. Pass it instead.
--
Gerry Ford
"Anybody who says, that a high-speed collision with water is the same as
with concrete, likely has more experience with the former than the latter."