How to trim to i.e. 2 decimal places in the Data window? - page 4

New comment
 
Keith Watford:

If I banned people for not thinking things through before posting, I would probably have banned myself  a few times by now Alain.

;D


 
The issue is, you try to fix a "bug" which is no bug, but given the basics of granularity.

Between the numbers 0.0 and 1.0 are infinite amount of possibilities, the underlying granularity used is 64 bit. To handle such numbers a standard was established, documented here:

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

In fact, your rounding procedure is in its basic approach already flawed.

Your suggestion on treating floating point numbers has more to do with raping the poor CPUs floating point unit.

Poor little thing.

Maybe after reading the specs, you come to the conclusion it is your expectations, that are wrong. Not the CPU.

And for cutting down a float to ie 2 digits, such a "treatment" of "buggy" numbers is unnecessary in the first place already.

Because the technical approach is anyways to cut of a string before plotting it to screen.

Nether the less a simple rounding would absolutely satisfying do the job, if this is wanted.

Normalize Double supports as input the digits to which you would want your float be treated.

So if you would have done research, you would not have gotten into such a fight with people who are obviously more experienced than you are.
 
Unfortunately I see a lot of people new to programming having a great confusion about floating-point arithmetic.
 
amrali:
Unfortunately I see a lot of people new to programming having a great confusion about floating-point arithmetic.
I have seen a lot of people NOT new to programming having a great confusion about it.
 
Alain Verleyen: I have seen a lot of people NOT new to programming having a great confusion about it.

In the old days of Machine Language or Assembly programming, where every single "bit" and "byte" was extremely important, we ALL knew how things were stored and represented.

Nowadays, with languages and concepts being relatively "high level", many don't have a clue how things are stored or computed at the lowest level. Most, don't even know what Assembly language looks like and even less about machine language or how a CPU works.

I still remember, in my youth, with great fondness programming Z-80 CPUs (8 bit) with HEX codes (using a Reference Book) and an EPROM programmer to burn in the code, and then using UV light to wipe it clean and reprogram it again to fix the bugs! What a pain that was, but also great fun! 😂

 
Fernando Carreiro:

In the old days of Machine Language or Assembly programming, where every single "bit" and "byte" was extremely important, we ALL knew how things were stored and represented.

Nowadays, with languages and concepts being relatively "high level", many don't have a clue how things are stored or computed at the lowest level. Most, don't even know what Assembly language looks like and even less about machine language or how a CPU works.

Yes exactly.

I still remember, in my youth, with great fondness programming Z-80 CPUs (8 bit) with HEX codes (using a Reference Book) and an EPROM programmer to burn in the code, and then using UV light to wipe it clean and reprogram it again to fix the bugs! What a pain that was, but also great fun! 😂

I also did such similar things
 
I missed out on that, my first machine was already a 286 with 8 MHz and stunning 1 MB mem.

But today's machines are much more fun, I think.


 
Alain Verleyen:
I have seen a lot of people NOT new to programming having a great confusion about it.
That is correct. I agree with you 👍 
 
Dominik Egert:
The issue is, you try to fix a "bug" which is no bug, but given the basics of granularity.

Between the numbers 0.0 and 1.0 are infinite amount of possibilities, the underlying granularity used is 64 bit. To handle such numbers a standard was established, documented here:

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

In fact, your rounding procedure is in its basic approach already flawed.

Your suggestion on treating floating point numbers has more to do with raping the poor CPUs floating point unit.

Poor little thing.

Maybe after reading the specs, you come to the conclusion it is your expectations, that are wrong. Not the CPU.

And for cutting down a float to ie 2 digits, such a "treatment" of "buggy" numbers is unnecessary in the first place already.

Because the technical approach is anyways to cut of a string before plotting it to screen.

Nether the less a simple rounding would absolutely satisfying do the job, if this is wanted.

Normalize Double supports as input the digits to which you would want your float be treated.

So if you would have done research, you would not have gotten into such a fight with people who are obviously more experienced than you are.




Thanks God,  here is at least one person who thinks(!), but not just shouting without real technical arguments, showing their "balls" how cool they are.. even if problem understanding is something "out of their minds".
Dominik Egert explained where real error comes from, it's "hardware level". (y)

Thank you Dominik, cos Im already tired to explain these noobs where is real problem and correct unswer to this topic main question is! ... ;)







 
It's not an error, it's by design.

It sources in the nature of mathematics and the technical limitations given by the fundentals of the universe we live in.


123456
New comment