debug output of very small or very large numbers

[Klaus_1963]

beta 12:

e.g.

Code: Select all

a.d = 1e-34
Debug a

=> Debug output: 0.0

[Fred]

debug use the default precision, use StrD() if you want more.

[Klaus_1963]

StrD() doesn't work too...

[Klaus_1963]

e.g.

Code: Select all

OpenConsole()
a.d = 1e-34
Print(StrD(a))
Input()

[luis]

Code: Select all

a.d = 1e-34
Debug StrD(a, 34)

[Klaus_1963]

debug output is not readable, unless you like to count zeros...

[luis]

PB does not support scientific notation with StrD afaik.
You can make your own "debug" routine, let it count the zeros for you, and print the rest of the string with the appropriate exponent.

[Klaus_1963]

I can't understand, why moving from bugs! in nearly every other programming language you can view small numbers without counting zeros... (analoge to very huge numbers...) . Maybe I don't know another command: if, please let me know.

thanks a lot

[luis]

I can't understand, why moving from bugs!

Because clearly it's not a bug. Make your request in the "Feature Requests and Wishlists" section of the forum.

[Klaus_1963]

it's clearly a bug! sorry...

[luis]

Didn't know. Thank you for the explanation. Why are you sorry ?

[Little John]

Code: Select all

a.d = 1e-34
Debug StrD(a, 34)

This only works, if we know beforehand how many digits have to be displayed. It is the case in this example, but normally we do not know the result beforehand ( that's the reason why we want to display it ). Then we'll have to use e.g. StrD(a, 50), and RTrim() in order to remove trailing zeros. IMHO it's a bug that PB doesn't do something like that automatically itself. Just using StrD(a) should show the correct result. (In what format the result should be is a different question.)

I can't understand, why moving from bugs! in nearly every other programming language you can view small numbers without counting zeros... (analoge to very huge numbers...).

Missing output in scientific format is no bug IMHO.

So it looks to me that we have a bug report and a feature request here.

[luis]

This only works, if we know beforehand how many digits have to be displayed.

That was for addressing his "does not work" in reply to Fred's suggestion.
It does work. Not in a way he likes ? In a cumbersome way ? I agree. But that's another story.
But he can have his number displayed instead of ZERO, so using StrD can work.

About the bug.
It would be a bug if PB was behaving in a way different from what documented.
Documented in case of PB means: the HELPFILE + the "programming by example" from the forum, and the occasional clarification on of how the things work internally made by Fred/Freak.
The source should be the documentation alone. But if we want to keep it real we should confront with the reality.

We learned PB uses StrD() with its default value when printing a double value to the debug window.
The StrD() doc says its default are 10 decimal places.
It's a very bad idea, I'm totally against this "10" default, but again that's another story -> http://www.purebasic.fr/english/viewtop ... =3&t=53614

EDIT: Actually after some test it seem it doesn't use StrD, precision is different.
EDIT: Anyway we learned the debug command use some kind of reduced precision, and that precision is not enough for very small numbers.

If he wants something different, posting this as a bug will not give it to him since it's not a bug, since there are not specification about the level of precision used. It's just doesn't have a precision sufficient for small numbers.
Posting a feature request about having scientific notation supported in numerical <-> string conversions could and this should solve it.

All these output should indeed be more coherent, but that's a job for a feature request IMO.

[Little John]

The StrD() doc says its default are 10 decimal places.
It's a very bad idea, I'm totally against this "10" default, but again that's another story -> http://www.purebasic.fr/english/viewtop ... =3&t=53614

No, IMHO that's not another story. StrD(a) should give the correct result (if possible). Not doing so is a bug.

About the bug.
It would be a bug if PB was behaving in a way different from what documented.

Please let me quote, errm ... you.

To me this is a bug, I don't care if the docs says differently.

[luis]

Please let me quote, errm ... you.

To me this is a bug, I don't care if the docs says differently.

Yes. And if you read the rest I wrote: -> http://www.purebasic.fr/english/viewtop ... 63#p421863

Again, formally, since the behavior is documented (even if objectionable) this should be made as a feature request.

I'll explain it in a easily understandable way, concentrate:

What is in my mind, my opinion, it's a thing. That one is a bug.
What I would do, based on the fact it's documented to work that way, is a different thing. I would put a feature request.
That one has been moved from coding questions to bugs BTW, if I'm not mistaken. Anyway is not important.

So your quotation was really ill-chosen since that is not different from what I'm saying here.

On a different note: seems debug use a precision similar to StrD(num,10) but not identical.
Anyway the root of all these problems IMO is the StrD() behavior. Working differently could be used even for the debug ouput limiting the problem exposed here.