I am attempting to use Entity Framework and have a contact database that has Longitude and Latitude data from Google Maps.
The guide says that this should be stored as float.
I have created my POCO entity which includes Longitude as a float and Latitude as a float.
I have just noticed that in the database, these both come up as real.
There is still a lot of work to be done before I can get any data back from Google, I am very far away from testing and I was just wondering if anyone can tell me if this is going to be a problem later on?
Nope, that should be fine. Note that you may not get the exact same value back as you received from Google Maps, as that would have been expressed in decimal-formatted text. However, this is effectively a physical quantity, and thus more appropriate as a float/double/real/(whatever binary floating point type you like) than as a decimal. (Decimals are more appropriate for man-made quantities - particularly currency.)
If you look at the documentation for float and real you'll see that real is effectively float(24) - a 32-bit floating binary point type, just like float in C#.
EDIT: As noted in comments, if you want more than the significant 7-8 digits of accuracy provided by float, then you probably want double instead in C#, which would mean float(53) in SQL Server.
This link:
http://msdn.microsoft.com/en-us/library/aa258876(v=sql.80).aspx
explains that, in SQL Server, real is a synonym for float(24), using 4 bytes of data. In .NET a Single precision floating point number also uses 4 bytes, so these are pretty much equivalent:
http://msdn.microsoft.com/en-us/library/47zceaw7(v=vs.71).aspx
Related
I have a SQL table which has two columns Latitude and Longitude with values 29.47731 and -98.46272 respectively. Column datatype is float in SQL server.
When we retrieve the record using EF core like _context.Table.ToListAsync(), it retrieves record but when it is converted to c# equivalent double? datatype, it adds extra digits like -98.4627199999999.
How can i avoid this? It should return same value as there in database.
SQL Float and C# Double are imprecise data types, they store very close approximations of the number, but often not the exact number. If you need to maintain the exact values, you should use SQL Numeric data type which will allow you to specify the number of significant digits; and while the C# Decimal data type is still imprecise, it will provide a higher precision approximation than Double does.
I you find out that your data isn't stable and you are dealing with decimal values, it is propably a 'precise notation' issue.
Try taking a look at these:
SQL:
https://learn.microsoft.com/en-us/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-ver15
C#
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/floating-point-numeric-types
Those should guide you trough using the most precise notation for your situation :-)
I am working with MongoDB v3.6.3.
I have seen a similar question that recieved a good answer. So why am I asking this question?
Because I am working with a different version of MongoDB
Because I have just stored a decimal number in my DB without registering any serializers as instructed in the answer of the similar question And no error was thrown.
My MongoDB schema looks like this:
rating:{
type: Number,
required: true
}
So my question is, is there anything wrong with the way I have implemented this. Considering that I have already stored a decimal number in my DB. Is it okay to store decimal numbers with the current schema? Or is this a setup for errors in the future because I am missing a step?
Thank you.
The Number type is a floating point numeric representation that cannot accurately represent decimal values. This may be fine if your use case does not require precision for floating point numbers, but would not be suitable if accuracy matters (for example, for fractional currency values).
If you want to store and work with decimal values with accuracy you should instead use the Decimal128 type in Mongoose. This maps to the Decimal 128 (aka NumberDecimal) BSON data type available in MongoDB 3.4+, which can also be manipulated in server-side calculations using the Aggregation Framework.
If your rating field doesn't require exact precision, you could continue to use the Number type. One reason to do so is that the Number type is native to JavaScript, while Decimal128 is not.
For more details, see A Node.js Perspective on MongoDB 3.4: Decimal Type.
I had a table with two columns for coordinates stored in. These columns were REAL datatype, and I noticed that from my application it was only showing 5 decimals for coordinates, and positions were not accurate enough.
I decided to change datatype to FLOAT, so I could use more decimals. It was for my pleasant surprise that when I changed the column data type, the decimals suddenly appeared without me having to store all the coordinates again.
Anyone can tell me why this happens? What happens with the decimal precision on REAL datatype?. Isn´t the data rounded and truncated when inserted? Why when I changed the datatype the precision came up with no loss of data?..
You want to use a Decimal data-type.
Floating point values are caluclated by a value and an exponenent. This allows you have store huge number representations in small amounts of memory. This also means that you don't always get exactly the number you're looking for, just very very close. This is why when you compare floating point values, you compare them within a certain tolerance.
It was for my pleasant surprise that when I changed the column data type, the decimals suddenly appeared without me having to store all the coordinates again.
Be careful, this doesn't mean that the value that was filled in is the accurate value of what you're looking for. If you truncated your original calculation, you need to get those numbers again without cutting off any precision. The values that it autofills when you convert from Real to Float aren't the rest of what you truncated, they are entirely new values which result from adding more precision to the calculation used to populate your Real value.
Here is a good thread that explains the difference in data-types in SQL:
Difference between numeric, float and decimal in SQL Server
Another helpful link:
Bad habits to kick : choosing the wrong data type
i have this statement :
Select STORE_NAME,STORE_LATITUDE,STORE_LONGTITUDE
from stores
where STORE_LATITUDE=24.6669863852163
and STORE_LONGTITUDE=46.69189453125
this statement should return one row and i am pretty sure that i put the correct latitude and longitude as they are in the Database Table but it returning null value and not the store that i am looking for but i can't find my mistake STORE_LATITUDE,STORE_LONGITUDE are declared as float
Floating point values are inherently approximations. It's really hard to get them to compare equal; the old adage about "close counts in hand-grenades and horseshoes" also applies to floating point computations.
What I'm trying to say is, you can't reliably test for equality between floating point numbers, ever.
You need a query something like this:
Select STORE_NAME,STORE_LATITUDE,STORE_LONGTITUDE
from stores
where STORE_LATITUDE BETWEEN 24.6669863852163 - 0.0001
AND 24.6669863852163 + 0.0001
AND STORE_LONGTITUDE BETWEEN 46.69189453125 - 0.0001
AND 46.69189453125 + 0.0001
By the way, 0.0001 degrees of latitude is equivalent to about 11 meters on the ground. It's unlikely that your store locations are anywhere near that accurate, because that's where the spherical assumption for the shape of the earth starts to fall apart.
The precision of a latitude datum like 24.6669863852163 is around 11 nanometers, or the size of a molecule of complex carbohydrate or some such thing. That's cool for molecular biology, but obviously overkill for a store finder.
Floats don't hold the precision correctly, if you need the exact precission then you have to with the decimal data Type .
in the above case you can re-define the values as Decimal(38,20) to store the longitude and latitude values.
If you are using SQL Server 2008 or later version, SQL Server supports SPATIAL data types, which has the functionality to hold the longitudes and latitudes and also does a lot of calculations on top of them.
You can find more about the spatial data types from here http://msdn.microsoft.com/en-us/library/bb933790.aspx
Try using cast() or convert()
Select STORE_NAME,STORE_LATITUDE,STORE_LONGTITUDE
from stores
where Convert(decimal(9,2),STORE_LATITUDE)=24.66
and Convert(decimal(9,2),STORE_LONGTITUDE)=46.69
Your code works fine in Sql Server 2008: sqlfiddle
Precision loss is one thing, but precision gain???
I have a text file w/ the following coordinates:
41.88694340165634 -87.60841369628906
When I paste this into SQL Server Mgmt Studio table view, it results in this:
41.886943401656339 -87.608413696289062
Am I dreaming? How is this possible?
I'm pasting from notepad, and it's raw text. Same problem if I type the characters directly.
Where does sql server get the extra precision from?
It's not adding precision, it's just rounding it to the nearest IEEE floating point representation. When you convert that back to decimal, it only LOOKS like it gained precision.
According to Books-On-Line:
Float: Approximate-number data types for use with floating point numeric data. Floating point data is approximate; therefore, not all values in the data type range can be represented exactly.
Emphasis mine.
I haven't personally seen this, but it might just be that the SQL server management studio shows the "representation" of the float i.e. how the value would be stored in the db. Remember that floats are all approximate anyway.