FputoString format

[guga]

Hi Guys

I`m updating a FputoString function and have some doubts about the scientific output format. In normal printf it seems that when dealing with Floating points, 0 can be represented as: 0.00000e+00, 0.00000e-00, or 0.000000 etc etc, right ?

My question is...this format to represent 0 is really necessary ? Shouldn´t it be simpler to represent it as a single 0 ?

What´s the purpose of using formats such as: 0.00000e+00, 0.000 etc etc ?

[daydreamer]

Hi Guys

I`m updating a FputoString function and have some doubts about the scientific output format. In normal print it seems that when dealing with Floating points, 0 can be represented as: 0.00000e+00, 0.00000e-00, or 0.000000 etc etc, right ?

My question is...this format to represent 0 is really necessary ? Shouldn´t it be simpler to represent it as a single 0 ?

What´s the purpose of using formats such as: 0.00000e+00, 0.000 etc etc ?

real4 and dword have in common zeros have same encoding,so if you want to you could use conditional jump and print "0",if you discover a zero
 

[FORTRANS]

Hi,

What´s the purpose of using formats such as: 0.00000e+00, 0.000 etc etc ?

   The first thing that comes to mind is output alignment.  Or "pretty
printing".

Regards,

Steve N.

[raymond]

Shouldn´t it be simpler to represent it as a single 0 ?

That was the philosophy for the FpuFLtoA function of the Fpulib, although it did include the possibility of front padding with spaces for potential "alignment" of the decimal delimiter when specified.

If you can have a logical reason to offer some other different option in your own functions, it would be entirely up to you (and be entirely acceptable as always).

[guga]

Thanks guys

Hi Raymond, thanks. I was thinking about removing this and keeping just 0, but maybe it would be better to add an optional flag in case someone wants this kind of output. I don't see any use for it, but maybe it will be useful for others.

[NoCforMe]

Hi Guys

I`m updating a FputoString function and have some doubts about the scientific output format. In normal printf it seems that when dealing with Floating points, 0 can be represented as: 0.00000e+00, 0.00000e-00, or 0.000000 etc etc, right ?

My question is...this format to represent 0 is really necessary ? Shouldn´t it be simpler to represent it as a single 0 ?

What´s the purpose of using formats such as: 0.00000e+00, 0.000 etc etc ?

False precision is all I can think of.

Heh; I'm always amused by seeing things on Microsoft Learn where they give constants like "0x00000001", where a simple "1" would suffice.

[guga]

Hi David. Yes, I agree. I usually opt for the simplest way. I'm updating another function that I created specifically for these conversions, but I got confused when I looked at the format that the M$ printf function exported when it came to FPU. I found it very strange. Unfortunately, it seems that some people use this, so I'm going to try to do as Raymond suggested and implement this as an option. The problem is trying to do it in a way that doesn't change the functionality too much (I mean, the processing speed). The worst thing is that I've already finished the function, it was ready, but I tried to look at this M$ function to see if I could adapt it to other ways of representing the FPU and I came across this weird format of 0.000e+00 etc.

[NoCforMe]

Hi David. Yes, I agree. I usually opt for the simplest way. I'm updating another function that I created specifically for these conversions, but I got confused when I looked at the format that the M$ printf function exported when it came to FPU. I found it very strange. Unfortunately, it seems that some people use this, so I'm going to try to do as Raymond suggested and implement this as an option. The problem is trying to do it in a way that doesn't change the functionality too much (I mean, the processing speed).

Again, I have to ask: WHY?
Who the hell cares how many more microseconds your conversion routine takes?
Think about it: you're converting a binary value to a visible format. Not some other internal binary format.
Which means that, by necessity, this is going to be used for some kind of output display, where speed is not of the essence. Not for converting into some other format where speed is important, like processing a huge database or some such.

Worst case, you could probably use wsprintf() to accomplish this formatting. (I use that function all the time.)

Just code the damn thing and be done with it.

[guga]

Which means that, by necessity, this is going to be used for some kind of output display, where speed is not of the essence. Not for converting into some other value where speed is important, like processing a huge database or some such.

Indeed. It makes sense.

[daydreamer]

I agree with David because afterwards print or SendMessage to a gui control takes Milliseconds

[sinsi]

If you write to a file or capture some output it might need to be a specific format when it gets parsed?
That's probably why printf etc differentiate between decimal and scientific output.

99.9% it won't matter.

Then again, the FPU can have -0 and +0 

[daydreamer]

If you write to a file or capture some output it might need to be a specific format when it gets parsed?
That's probably why printf etc differentiate between decimal and scientific output.

99.9% it won't matter.

Then again, the FPU can have -0 and +0 

Latest calculator i made had support for showing unicode infinity and - infinity

[NoCforMe]

Then again, the FPU can have -0 and +0 

True, but do we really need to display that?
I mean, when does it matter to us which zero the FPU is giving us?

[guga]

Then again, the FPU can have -0 and +0 

True, but do we really need to display that?
I mean, when does it matter to us which zero the FPU is giving us?

yeah. I saw that too. But it´s useless IMHO (Unless we are working with Imaginary numbers, i suppose). Allowing the function output only +Infinite or -Infinite is enough.

[daydreamer]

Unicode Character "∞" (U+221E)
For those who want to use it in gui control,use with invoke sendwmessage