1
00:00:00,480 --> 00:00:06,060
So we discussed the decimal type and you've already seen the end type, but we're focusing on the decimal

2
00:00:06,060 --> 00:00:08,160
type or we did focus on it.

3
00:00:08,370 --> 00:00:11,070
But like I said, there's a bit of competition.

4
00:00:11,490 --> 00:00:16,890
So there are other types that we could use to represent similar data, which is to say numbers that

5
00:00:16,890 --> 00:00:18,210
are not whole numbers.

6
00:00:19,170 --> 00:00:25,170
So there's also things like float and double.

7
00:00:25,740 --> 00:00:27,660
So we're going to talk about those in this video.

8
00:00:28,020 --> 00:00:33,570
The differences have to be up front between all of them are quite technical.

9
00:00:33,570 --> 00:00:36,090
They have to do with how things are stored in memory.

10
00:00:37,020 --> 00:00:44,430
It would be difficult to explain without going all the way into how binary works and base ten versus

11
00:00:44,430 --> 00:00:47,180
base two and how things are stored in memory.

12
00:00:47,190 --> 00:00:53,820
So I'm going to kind of skim over some of this because the honest answer is that it doesn't or the truth

13
00:00:53,820 --> 00:00:55,890
is that it doesn't really matter.

14
00:00:56,100 --> 00:00:58,830
All that matters is that, you know, functionally what the differences.

15
00:00:58,830 --> 00:01:03,690
But if you do want to learn more about the difference between them, there are some good resources online

16
00:01:03,690 --> 00:01:08,400
and I highly recommend that you check out some YouTube videos and I would love to link you to a specific

17
00:01:08,400 --> 00:01:08,910
one.

18
00:01:09,000 --> 00:01:13,230
However, I've had some copyright claim issues, so last time I did that, I'm not going to do it.

19
00:01:13,230 --> 00:01:15,510
Now, if you're curious, you can research it.

20
00:01:15,720 --> 00:01:18,840
But essentially, like I said, it boils down to how they're stored.

21
00:01:18,840 --> 00:01:23,820
So the big question is what is the difference between float and double?

22
00:01:23,820 --> 00:01:26,700
Let's take them as a unit and decimal.

23
00:01:27,000 --> 00:01:33,240
And if we go to the documentation, there's a page that lays it out relatively plainly.

24
00:01:33,240 --> 00:01:38,550
It says the decimal data type is a fixed point type and calculations are exact.

25
00:01:39,000 --> 00:01:44,850
The float and double data types are floating point types and calculations are approximate.

26
00:01:45,240 --> 00:01:48,390
So we've got fixed point and floating point.

27
00:01:48,390 --> 00:01:49,250
They are different.

28
00:01:49,260 --> 00:01:53,460
That's that has to do with how what I was describing how they're stored in memory is different.

29
00:01:55,260 --> 00:01:56,430
That's not as important.

30
00:01:56,430 --> 00:01:58,550
Just knowing that they are different is important.

31
00:01:58,560 --> 00:02:05,640
However, the side effect of how they're stored is that float and doubles are approximate, which seems

32
00:02:05,640 --> 00:02:06,480
kind of weird.

33
00:02:07,350 --> 00:02:14,880
It doesn't seem like you would ever want to use them if they are not exact, but essentially they approximate

34
00:02:15,210 --> 00:02:17,340
and decimals are exact.

35
00:02:19,140 --> 00:02:25,230
So to boil it down, float and double will store larger numbers using less space.

36
00:02:25,230 --> 00:02:26,460
So that's an advantage.

37
00:02:26,910 --> 00:02:30,870
They can take gigantic numbers, things that you can't store in a decimal.

38
00:02:31,560 --> 00:02:33,510
And they'll use less space.

39
00:02:33,750 --> 00:02:35,560
However, that comes at a big cost.

40
00:02:35,580 --> 00:02:36,540
It's a big but.

41
00:02:37,570 --> 00:02:39,250
It comes with the cost of precision.

42
00:02:40,390 --> 00:02:46,240
So it doesn't mean that your numbers will be wildly inaccurate if you're using a float or a double.

43
00:02:46,690 --> 00:02:49,930
But it does mean that they're not going to be as accurate as a decimal.

44
00:02:51,370 --> 00:02:59,140
So here's a simple table that it just basically takes information from the documentation floats will

45
00:02:59,140 --> 00:03:02,860
have precision issues after around seven digits.

46
00:03:03,640 --> 00:03:05,770
So if we had something like.

47
00:03:08,710 --> 00:03:14,320
This number here, we could run into a problem where this one might not reliably be one.

48
00:03:14,320 --> 00:03:21,250
When we retrieve it, it might change and that could be problematic if you need it to be precise.

49
00:03:21,910 --> 00:03:27,670
But if you're working with gigantic numbers, something like this or let's even add in something like

50
00:03:27,670 --> 00:03:35,170
this, this one at the very end isn't going to be a deal breaker most of the time, depending on what

51
00:03:35,170 --> 00:03:36,010
you're working with.

52
00:03:36,580 --> 00:03:42,010
With that said, it's really important to know that there is difference and there's a lot of kind of

53
00:03:42,010 --> 00:03:44,050
classic bugs and issues.

54
00:03:44,050 --> 00:03:50,770
People have run into lots of blog posts around floating point math problems, floating point math issues

55
00:03:50,770 --> 00:03:51,610
and bugs.

56
00:03:52,570 --> 00:03:55,420
Doubles are basically the same thing as a float.

57
00:03:55,450 --> 00:03:56,530
They're just bigger.

58
00:03:56,530 --> 00:03:58,420
They have larger capacity.

59
00:03:58,420 --> 00:04:01,120
However, they take up more space in memory.

60
00:04:01,940 --> 00:04:04,180
As you can see, four bytes versus eight bytes.

61
00:04:04,930 --> 00:04:07,480
A double, however, is more precise.

62
00:04:08,150 --> 00:04:12,410
So it's precise to roughly 15 digits rather than just seven.

63
00:04:13,160 --> 00:04:16,940
So if you do use one of these, it's better to use double.

64
00:04:17,510 --> 00:04:24,110
Which brings us to the question what numeric data type should you use when you're storing information

65
00:04:24,110 --> 00:04:25,310
that has a decimal?

66
00:04:25,370 --> 00:04:31,460
And the answer, at least in my opinion, is you should always try and use decimal unless you know that

67
00:04:31,460 --> 00:04:32,670
precision doesn't matter.

68
00:04:32,690 --> 00:04:39,410
So if you're doing things like financial data prices, if you're a bank, you need that precision.

69
00:04:39,410 --> 00:04:40,370
Absolutely.

70
00:04:40,370 --> 00:04:41,630
You need to use decimal.

71
00:04:41,660 --> 00:04:45,320
Otherwise you can get away by with floats or doubles.

72
00:04:45,560 --> 00:04:48,020
But for the most part I'll be using decimal.

73
00:04:48,110 --> 00:04:51,950
It's kind of my preferred data type when we're working with decimals.

74
00:04:52,730 --> 00:04:54,440
Oh, and before I forget.

75
00:04:54,440 --> 00:04:58,610
Well, actually, I already forgot, but this is after I recorded the video.

76
00:04:58,640 --> 00:05:00,310
I'm going and adding this in.

77
00:05:00,320 --> 00:05:07,460
I wanted to show you that you can actually see the inconsistency, the imprecise ness of using floats

78
00:05:07,550 --> 00:05:09,410
and doubles as well.

79
00:05:09,410 --> 00:05:19,130
So I'm going to create a simple table and I will just call it Let's go with thingies.

80
00:05:20,940 --> 00:05:21,570
Right on.

81
00:05:21,810 --> 00:05:23,870
Great table thing isn't all that is going to happen.

82
00:05:23,880 --> 00:05:30,000
There is a price which will go with float.

83
00:05:31,680 --> 00:05:38,730
So then we'll do our insert into thingies and we'll do what we need to do.

84
00:05:38,730 --> 00:05:41,970
Price values.

85
00:05:42,660 --> 00:05:44,280
And let's start with a simple one.

86
00:05:44,280 --> 00:05:50,820
Let's do 88.45 and if we select that out of there,

87
00:05:54,900 --> 00:06:03,510
good, we get 88.45, but we'll run into problems if we start making more complex, longer numbers.

88
00:06:03,510 --> 00:06:11,640
So let's do something like 88, 77.45, and that should still work.

89
00:06:12,660 --> 00:06:15,300
If we select it out, you can see it's unchanged.

90
00:06:15,300 --> 00:06:19,170
Remember, we're working with four, five, six characters here.

91
00:06:19,170 --> 00:06:24,960
And if we go back to that table that I had says around seven issues, we run into precision problems,

92
00:06:25,680 --> 00:06:28,020
seven characters run into precision problems.

93
00:06:28,770 --> 00:06:35,340
So if we do something a little longer now eight, eight, seven, seven, six, six, five, five,

94
00:06:35,340 --> 00:06:41,310
four, four and we hit enter notice how it got stored.

95
00:06:41,940 --> 00:06:48,180
So it doesn't just truncate, it doesn't chop things off, but it only stores the first seven digits

96
00:06:48,780 --> 00:06:51,270
and then it just puts these empty tens places.

97
00:06:51,270 --> 00:06:56,010
Well, not tens places, but it multiplies by ten add zeros essentially at the end.

98
00:06:56,610 --> 00:07:00,210
So we end up with this, which is very different than this.

99
00:07:02,080 --> 00:07:08,530
And if we instead had this as a double instead of a float, we would have that precision extended out

100
00:07:08,530 --> 00:07:09,850
to 15 characters.

101
00:07:10,480 --> 00:07:15,610
So it is significant and it makes a big impact depending on what you're doing and what you need.

102
00:07:16,270 --> 00:07:22,510
So that's why I recommend using decimal, where you can control exactly what you need and how long you

103
00:07:22,510 --> 00:07:23,350
need things to be.

104
00:07:23,380 --> 00:07:27,910
However, if you're working with gigantic numbers and you don't need to be that precise, you can use

105
00:07:27,910 --> 00:07:29,560
double or float.

106
00:07:29,560 --> 00:07:35,830
But typically my rule of thumb is if you need to use one, use double rather than float because you

107
00:07:35,830 --> 00:07:41,710
have 15 characters, 15 places of precision rather than seven.

108
00:07:42,250 --> 00:07:44,380
You get double the precision.