interesting. I had thought they just had other, non-standardized ways of doing floats but they still had floating point units in the CPU. I'm going to have to read about this now
@@CodeSlate Correct me if i'm wrong, but as i'm aware, i think it was common that home computer CPUs used from the 70's to 90's to not have floating point integrated... Iirc, 6510 / 6502 and Motorola 68k don't have floating points. One was used in Commodore and the other on Sega Genesis.
Yes, floor and ceiling are definitely useful when you need to do some floating point math but want an integer result at the end. For example, when you'll use it to index an array. Thanks for commenting!
but how do you use floor or ceil if you dont knoe wrsther the inaccuracy is less then the expected result or more than it? (weather uts 0.999999997 or 1.00000000013)
@@tam_69420 I'm guessing you use one based on what you're doing. You already know what you're doing, you're starting with integer calculations and trying to make them stay integers.
Actually floating point is no more an approximation than decimal numbers are. It's just that the numbers you can write exactly as floating point are not the same as those you can write exactly in decimal.
That's true. Most people are coming from a frame of reference of using decimals in their day to day life, so 0.3 seems like a normal, typical number (that has an exact value in base 10) whereas you have to approximate it (coming from that frame of reference) in binary. Thanks for commenting!
Back when I took my Computer Science degree (specifically, IBM MASM assembly language) it was always stated that microprocessors (of that time period) perform integer operations 200 times faster than floating point operations. For this reason alone, it was always recommended to analyze the range of Real Numbers that your Assembly Language program would have to deal with, and, somehow, "map" such numbers onto an appropriate range of Integers. So, as a result, behind the scenes, your program would be exclusively performing integer operations.
Thanks for commenting! Another comment mentioned the same thing. From what I read while researching this and my other float videos, floats were historically slower but the hardware has been getting optimized for multiple decades at this point, so that's not the case any more. I'm not really a hardware guy but I believe the performance for add and multiply with floats is now comparable to integers. Plus you have GPU/TPU capabilities now, and those are highly optimized for fast, massively parallel floating point operations.
The answer is A, since when you check the binary value of 0.3, you see the same pattern - an infinitely repeating loop of 1100, until it ends with 1101. This shows us the computer rounds up 0.3, which can result in a floating point inaccuracy
Thanks for commenting! A is definitely part of the answer, but like I said, it's a bit of a trick question. Maybe look at some of the possible choices, too...
@@CodeSlate I believe I get it now, is it all of them? 2.33 is infinitely repeating, 0.3 is infinitely repeating, 0.2 is infinitely repeating and both 9.99 and 3.13 are infinitely repeating. in short, all the calculations might incur a calculation error!
I find it interesting how rare it is I run into this oroblem, despite mostly writing in JavaScript, which doesn't actually even have native integers. I also find it interesting how I've always just used greater than or less than for loops, even with integers. It's just how I learned the for loop when going from QBASIC to C-like languages. I was never formally taught and just read books.
Thanks for commenting! I don't use JS myself but I believe it uses 64-bit floats for all numbers, which can exactly represent all integers up to a fairly high value. So it may not be an issue for you. For how often someone might run into this, it depends on what kind of code you're writing. If there's a lot of number crunching involved and you're taking time to manually inspect a lot of values, this problem can show up sooner rather than later.
Is the answer all of them? It's not just recurring decimals that can't be represented accurately by floating point binary. An infinite number of seeming arbitrary decimal numbers can't be represented either, because they don't coincide exactly with one of the finite selection of floating point numbers available. (Presumably 4 billion ish possibilities for 32 bits). Floating point numbers, being binary, are discrete, not continuous like real numbers.
Thanks for answering! It may be implementation dependent. I did most of the testing for this with C++ and 32-bit floats. Python uses 64-bit floats by default, which can still have floating point problems but will have more decimal places before it shows up.
I was in Java for a long time but for past few years more Python. C++ was my first language but that was quite a while ago. Now I come back to it every now and then for simple stuff. What about you?
all sacred. Material absolute's simply a distraction from what was originally stated in the sacred offering in terms, even, (eden) evenly, edenly dividable. The sacred always expressing a completion beyond material di-mensioning. A completion that can be illustrated in the term, "this and a little bit" the little bit re-vealing exponentially more than the whole material seen. Your example of the 5 and 2 is re-vealing these sacred verities through material proof. .5, 1/2, .2, 1/5 a sacred "reflective for understanding beyond the material di-mension-ing and as expressed in the first known math constants 1,11 and the relationship aspect 1/11 The first pairing expressing variation and the foundation for understanding all variation that exists.
I liked your hex video, but I don't watch videos or sub to channels that use gen AI. I just wanted to mention this since there are a lot of us who absolutely do not interact or engage with anything that uses it. While you might save some time or money having it generate quick but bad thumbnails, you are losing an audience that will either ignore or hit the 'not interested' button. Normally I'd not say anything but, as I said, I enjoyed your hex video. I think your videos warrant better representation than genAI.
Thanks for watching! I have a lot of fun using AI to make images and incorporated some of those images into this video. It's not like the whole video is AI. But you and several other viewers have commented that they don't like it, so I will probably not use AI generated images in the future as much as I did in this video.
Thanks for the feedback! I am just having fun trying out a new AI generator. I thought the AI pics were funny but maybe you are right, some of them look pretty odd.
Thanks, this is a great and welcome contribution! I actually had a line in the script about checking for equality within a small tolerance but could not figure out how to visualize it well so it got cut.
Back in the old days (before IEEE) you had to implement floating point _yourself_ in assembly language. It really drives home the point.
interesting. I had thought they just had other, non-standardized ways of doing floats but they still had floating point units in the CPU. I'm going to have to read about this now
Me when no Libs
Drives home THE POINT
I'm surprised they even used them, instead of fixed point.
@@CodeSlate Correct me if i'm wrong, but as i'm aware, i think it was common that home computer CPUs used from the 70's to 90's to not have floating point integrated...
Iirc, 6510 / 6502 and Motorola 68k don't have floating points. One was used in Commodore and the other on Sega Genesis.
Well. Now I know why floor and ceiling functions are useful
Yes, floor and ceiling are definitely useful when you need to do some floating point math but want an integer result at the end. For example, when you'll use it to index an array. Thanks for commenting!
but how do you use floor or ceil if you dont knoe wrsther the inaccuracy is less then the expected result or more than it? (weather uts 0.999999997 or 1.00000000013)
@@tam_69420 I'm guessing you use one based on what you're doing. You already know what you're doing, you're starting with integer calculations and trying to make them stay integers.
Actually floating point is no more an approximation than decimal numbers are. It's just that the numbers you can write exactly as floating point are not the same as those you can write exactly in decimal.
That's true. Most people are coming from a frame of reference of using decimals in their day to day life, so 0.3 seems like a normal, typical number (that has an exact value in base 10) whereas you have to approximate it (coming from that frame of reference) in binary. Thanks for commenting!
Back when I took my Computer Science degree (specifically, IBM MASM assembly language) it was always stated that microprocessors (of that time period) perform integer operations 200 times faster than floating point operations. For this reason alone, it was always recommended to analyze the range of Real Numbers that your Assembly Language program would have to deal with, and, somehow, "map" such numbers onto an appropriate range of Integers. So, as a result, behind the scenes, your program would be exclusively performing integer operations.
Thanks for commenting! Another comment mentioned the same thing. From what I read while researching this and my other float videos, floats were historically slower but the hardware has been getting optimized for multiple decades at this point, so that's not the case any more. I'm not really a hardware guy but I believe the performance for add and multiply with floats is now comparable to integers. Plus you have GPU/TPU capabilities now, and those are highly optimized for fast, massively parallel floating point operations.
The answer is A, since when you check the binary value of 0.3, you see the same pattern - an infinitely repeating loop of 1100, until it ends with 1101. This shows us the computer rounds up 0.3, which can result in a floating point inaccuracy
Thanks for commenting! A is definitely part of the answer, but like I said, it's a bit of a trick question. Maybe look at some of the possible choices, too...
@@CodeSlate I believe I get it now, is it all of them? 2.33 is infinitely repeating, 0.3 is infinitely repeating, 0.2 is infinitely repeating and both 9.99 and 3.13 are infinitely repeating. in short, all the calculations might incur a calculation error!
Great understanding!
I find it interesting how rare it is I run into this oroblem, despite mostly writing in JavaScript, which doesn't actually even have native integers.
I also find it interesting how I've always just used greater than or less than for loops, even with integers. It's just how I learned the for loop when going from QBASIC to C-like languages. I was never formally taught and just read books.
Thanks for commenting! I don't use JS myself but I believe it uses 64-bit floats for all numbers, which can exactly represent all integers up to a fairly high value. So it may not be an issue for you. For how often someone might run into this, it depends on what kind of code you're writing. If there's a lot of number crunching involved and you're taking time to manually inspect a lot of values, this problem can show up sooner rather than later.
Is the answer all of them? It's not just recurring decimals that can't be represented accurately by floating point binary. An infinite number of seeming arbitrary decimal numbers can't be represented either, because they don't coincide exactly with one of the finite selection of floating point numbers available. (Presumably 4 billion ish possibilities for 32 bits). Floating point numbers, being binary, are discrete, not continuous like real numbers.
This guy gets it!
TL;DR: they’re binary, so they don’t reprerent decimal exactly
That's an apt summary! Thanks for commenting
under rated youtuber!
Thanks, hope to put out more content soon!
3:22
D option will give you inaccuracy.
btw, I have python prompt opened.
Thanks for answering! It may be implementation dependent. I did most of the testing for this with C++ and 32-bit floats. Python uses 64-bit floats by default, which can still have floating point problems but will have more decimal places before it shows up.
I have an HP calculator that uses nonstandard floats. I had to write a program to convert.
Interesting, I don't know how it would work outside of IEEE 754 standard
just always round them to like one decimal point
you can round them when you print them out, but the loss of precision due to the representation (as discussed in the video) will still be there
@@CodeSlate oh yeah, forgot about precision loss
Which programming languages do you use normally?
I was in Java for a long time but for past few years more Python. C++ was my first language but that was quite a while ago. Now I come back to it every now and then for simple stuff. What about you?
all sacred. Material absolute's simply a distraction from what was originally stated in the sacred offering in terms, even, (eden) evenly, edenly dividable. The sacred always expressing a completion beyond material di-mensioning. A completion that can be illustrated in the term, "this and a little bit" the little bit re-vealing exponentially more than the whole material seen. Your example of the 5 and 2 is re-vealing these sacred verities through material proof. .5, 1/2, .2, 1/5 a sacred "reflective for understanding beyond the material di-mension-ing and as expressed in the first known math constants 1,11 and the relationship aspect 1/11 The first pairing expressing variation and the foundation for understanding all variation that exists.
The answer at the end is C.
Hey, good effort! And thanks for commenting. You're on the right track, but maybe have a closer look...
I liked your hex video, but I don't watch videos or sub to channels that use gen AI. I just wanted to mention this since there are a lot of us who absolutely do not interact or engage with anything that uses it. While you might save some time or money having it generate quick but bad thumbnails, you are losing an audience that will either ignore or hit the 'not interested' button. Normally I'd not say anything but, as I said, I enjoyed your hex video. I think your videos warrant better representation than genAI.
Thanks for watching!
I have a lot of fun using AI to make images and incorporated some of those images into this video. It's not like the whole video is AI. But you and several other viewers have commented that they don't like it, so I will probably not use AI generated images in the future as much as I did in this video.
Really great explanation!
Please, do not use AI images, they look so cursed! ><
Thank you!
Thanks for the feedback! I am just having fun trying out a new AI generator. I thought the AI pics were funny but maybe you are right, some of them look pretty odd.
I agree, that it could be fun, but sorry, in this case I could not resist to say that in the comments :P
Nevertheless, cool video!
you can also use math.isclose
math.isclose(.1+.2, .3) # returns true
.1+.2 == .3 # returns false
Thanks, this is a great and welcome contribution! I actually had a line in the script about checking for equality within a small tolerance but could not figure out how to visualize it well so it got cut.