1 00:00:02,130 --> 00:00:05,880 So we talked a lot about int 32 and int 64 2 00:00:05,990 --> 00:00:08,630 and these are super important topics. 3 00:00:08,810 --> 00:00:16,220 Let me really highlight again that we can sort with these types of numbers, that we can query for them 4 00:00:16,220 --> 00:00:19,930 with greater than and all the things you could do with the normal numbers, 5 00:00:19,940 --> 00:00:27,020 these things are possible with number int and number long too or with int 32 and int 64 as I should 6 00:00:27,020 --> 00:00:33,230 say because number int and number long are really just the constructors we use in the shell to create these 7 00:00:33,230 --> 00:00:34,640 number types. 8 00:00:34,640 --> 00:00:40,580 But let's now move towards our high precision double because that will also be interesting to understand. 9 00:00:41,420 --> 00:00:43,570 To understand what it does, 10 00:00:43,580 --> 00:00:49,140 let's say we have some database which we use for scientific calculations. 11 00:00:49,220 --> 00:00:55,100 So I have my collection science in there and I insert one new document and let's say we have two 12 00:00:55,100 --> 00:01:02,730 values, A which is .3 and B which is .1 13 00:01:02,730 --> 00:01:08,200 and please note these are the normal numbers as I used them in the shell and therefore, because the shell 14 00:01:08,200 --> 00:01:11,780 is based on Javascript, these are 64 bit floating point numbers, 15 00:01:11,830 --> 00:01:15,480 so they are not these high precision decimals. 16 00:01:15,610 --> 00:01:22,870 If I insert this, this will work, if I then find all my elements in there, 17 00:01:22,960 --> 00:01:23,910 this looks good right, 18 00:01:23,920 --> 00:01:26,200 the values look the way I store them. 19 00:01:26,200 --> 00:01:28,930 Now keep in mind what I mentioned earlier in this module, 20 00:01:29,080 --> 00:01:33,470 behind the scenes they will actually be stored with something like this. 21 00:01:33,730 --> 00:01:38,290 So there will be more decimal places than you see here and there will be some imprecision, 22 00:01:38,370 --> 00:01:41,220 it simply approximated to this and Javascript, 23 00:01:41,230 --> 00:01:46,880 so the shell here simply outputs it in this approximated value which of course looks all right here. 24 00:01:47,320 --> 00:01:52,870 But we can see the difference if we do a calculation with the help of the aggregate function, so of the 25 00:01:52,870 --> 00:01:55,060 aggregation framework. Here 26 00:01:55,120 --> 00:02:00,780 I only want to pass one stage, one step in my pipeline and that is the projection stage, 27 00:02:00,910 --> 00:02:06,630 so I will find all elements and project them into something new and there I will add a new field and 28 00:02:06,630 --> 00:02:13,050 let's name this result, whatever you want. And the value for this field has to be a document as you learned 29 00:02:13,060 --> 00:02:15,460 in the aggregation framework module 30 00:02:15,460 --> 00:02:24,250 and here I will subtract. I will subtract two values which are passed to this array and I will subtract 31 00:02:25,280 --> 00:02:27,490 a and b 32 00:02:27,830 --> 00:02:32,930 and they have to be referenced with dollar signs here so that mongodb will look for these 33 00:02:33,770 --> 00:02:34,730 fields. 34 00:02:35,060 --> 00:02:41,800 If I hit enter here, you see something strange, the result of A - B is not 0.2 35 00:02:41,820 --> 00:02:43,600 as you would have expected 36 00:02:44,150 --> 00:02:48,780 but this value and this shows you the imprecision I'm talking about. 37 00:02:49,040 --> 00:02:56,300 These values are not stored exactly and in some use cases, in a lot of use cases, this might not matter even 38 00:02:56,510 --> 00:03:01,580 if you are building an online shop with products where you store the price where you would say of course 39 00:03:01,610 --> 00:03:01,990 I don't 40 00:03:01,990 --> 00:03:08,780 want to lose some fraction of a cent, even in such a case, you could be fine with these values here 41 00:03:10,380 --> 00:03:16,360 because you might only use that price to display it on your web page where the approximation will be 42 00:03:16,400 --> 00:03:16,820 all right 43 00:03:16,830 --> 00:03:21,300 because you don't have that many digits you approximate, you only show two decimal places and these 44 00:03:21,300 --> 00:03:22,990 will be correct. 45 00:03:23,220 --> 00:03:30,240 And even for you then kind of charging this, you might be fine because you send this to some third party 46 00:03:31,170 --> 00:03:31,870 service, 47 00:03:31,950 --> 00:03:35,300 you send your value as it is returned by the database, 48 00:03:35,310 --> 00:03:40,950 so something like this, you send that to the provider and you then rely on the provider charging exactly 49 00:03:40,950 --> 00:03:44,100 that and not some incrementally lower amount. 50 00:03:44,100 --> 00:03:50,700 So you might be fine using these values but if you do calculations with them, if you work with them on 51 00:03:50,700 --> 00:03:55,660 the server here because aggregate of course executes this on the mongodb server, 52 00:03:55,830 --> 00:04:01,680 so if you do something like this where you extract data, return value from the database and you end up 53 00:04:01,920 --> 00:04:08,490 with a result like this, you might of course have a problem because that is probably not acceptable for 54 00:04:08,490 --> 00:04:09,830 your application then 55 00:04:10,260 --> 00:04:16,420 and this is exactly where this high precision double, the 128 bit double can help you. 56 00:04:16,440 --> 00:04:18,390 So let's have a look at that in the next lecture.