Strange GPX writing in BaseCamp (modified values and syntax error)

I have similar problems with waypoint averaging on a Montana 650 that generates long decimal numbers and also xml syntax errors for the number of averaged samples. Makes me wonder if Garmin has a problem with their code for generating xml

1)
Editing and saving a track (to a new gpx file) in BaseCamp leads to modified elevation values. For example the 784.57 elevation data is modified to 784.57000000000005; 782.65 is modified to 782.64999999999998. Why? These very long decimal numbers (with slightly modified values!) cannot be handled by some programs. For example Global Mapper (a very good mapping software) doesn't read any elevation value from gpx files, if they ar formatted with such long decimal numbers.
2)
Adding new track points in BaseCamp to an exisiting track leads to a gpx/xml syntax error. Of course these new track points lack elevation and time&date datas. This is self-evident and not a problem. BUT the new <trkpt> tags are not closed with </trkpt>! This is definitely a syntax error. And some other programs cannot see these unclosed trackpoints. The GPSBabel converting program corrects them closing them with </trkpt>.

1.

The long decimals are caused by the way numbers are stored by computers (to a computer, once you store 784.57 as a number, not a string, it becomes 784.57000000000005). We could look into shortening the numbers when saving, but then they would become more and more imprecise when loading and reloading the gpx file. So I am not sure that is desirable. We can also check if rounding them before saving makes sense, but then again, in other cases that could cause a loss of precision that is not desirable. Long story short this is not as straight-forward of a thing as it might appear at first glance.

Inherently, there is nothing wrong with these long numbers, and Global Mapper should be able to read those.

2.

I cannot reproduce this, and it seems very odd. Our XML processor should always put closing tags. So something must go very wrong for this to happen. Could you describe the exact steps that I could reproduce this with?

I have similar problems with waypoint averaging on a Montana 650 that generates long decimal numbers and also xml syntax errors for the number of averaged samples. Makes me wonder if Garmin has a problem with their code for generating xml

That is a different issue. The devices use a different mechanism for writing GPS. They pretty much just write stuff into a text file (inserting new tags wherever needed). BaseCamp has the full XML tree in memory and re-writes the full file every time it changes.

The waypoint averaging issue is known. But it cannot hurt to complain to product support about it, the device team should be able to fix that with a firmware update.