How does MonkeyC interpret numbers with more decimal places than Double can handle

if you don't have an "f" at the end it's still a 32 bit float, with a "d" it's a double.

I think the JSON only produces float (not double).

Things generally ignore the digits they can't use.

Yeah the question has been raised previously regarding how to get makeWebRequest() interpret a number in a JSON response as a Double rather than a Float, and unfortunately the answer is you can’t. (The workaround is to change the API to return a string, if you can.)

You're saying that if an api returns the JSON {"PI" : 3.1415926535897932384626433832795028841971693d}, then the item would be passed (through to the response call back) in the dictionary as a double?

Try it and see.

I would probably just pass it as a string and then do a toDouble() on that string

You don't know then, but just thought you'd throw a random guess out into the mix?

Ultra said:

You're saying that if an api returns the JSON {"PI" : 3.1415926535897932384626433832795028841971693d}, then the item would be passed (through to the response call back) in the dictionary as a double?

No. The “d”’at the end is not valid JSON.

(It’s valid in Monkey C code.)

Ultra said:

You don't know then, but just thought you'd throw a random guess out into the mix?

Are you sure you want to establish yourself as someone no one wants to try to help?

dpawlyk said:

Ultra said:

You're saying that if an api returns the JSON {"PI" : 3.1415926535897932384626433832795028841971693d}, then the item would be passed (through to the response call back) in the dictionary as a double?

No. The “d”’at the end is not valid JSON.

(It’s valid in Monkey C code.)

Ultra said:

You don't know then, but just thought you'd throw a random guess out into the mix?

Are you sure you want to establish yourself as someone no one wants to try to help?

In all fairness, the first response to OP mentioned "f" and "d", ignoring the clear context where the OP says "web api" which implies they're asking about makeWebRequest and JSON (which others picked up on.). Then when it became clear that this was the case and OP asked if "d" could actually be used in a JSON response, they get a flippant/condescending response which acts like the use of "d" (which won't work) wasn't suggested in the first place, even though it clearly was.

The subtext (which should be obvious to everyone) is:

"Why did you reply with information about "f" and "d" when it's not applicable to my exact situation?" (since we're obviously talking about a JSON web response and not numerical literals in Monkey C code.)

"Because I didn't bother to fully read or understand your original post, and I don't care to clarify my original reply, but of course I will never admit that. Instead I will imply that *you* are the one who is ignorant for not realizing that my reply is only relevant to a different situation."

This has happened many times, where someone doesn't bother to fully read the OP, throws out a reply based on a few key words that's misleading and/or has varying degrees of irrelevance or incorrectness, then acts defensive or rude when called out on it.

IMO asking and answering questions is a two way street. Of course it's very much appreciated when people take the time to answer questions, but I think it's very frustrating when people don't bother to try to understand the question that's being asked. It almost implies a lack of respect for person asking the question. Almost as if people are replying in order to get cheap internet points, as opposed to actually making a thoughtful attempt to help others.

Then if asked for clarification or called out for literally incorrect information (not in this case), they either become defensive and/or double down. Not once have I seen the follow up reply "oops, I didn't fully read or understand the OP, sorry about that!" or "sorry for the misleading or incorrect info, my bad!"

Then there's the pattern of defending Garmin against any and all criticism, minimizing bugs, and often assuming that when a bug is reported (either in CIQ or in a device), the problem is actually that the reporter is "holding it wrong" (lack of respect for the person reporting the bug, with the assumption that they have no idea what they're talking about.)

Example: people complain for over ten years that Garmin Connect doesn't support mixed metric and imperial/statute units. Instant off-the-cuff reply to latest post: "Actually Garmin watches have supported mixed units for years. [Proceeds to explain how to change setting on device]" Yeah, the situations for the device itself and the Garmin Connect app/website are not the same. But ofc the immediate assumption was that all of those people who have been complaining for over a decade have no idea what they're talking about. Ofc the same person who has replied "try it and see" more than once will often not bother to try to recreate a problem mentioned in the OP before replying.

I wouldn't say anything if this wasn't literally a years-long pattern and if it wasn't for the unfortunate situation where subtly incorrect information is sometimes accepted as gospel on these forums, depending on the source. A recent example is the misinformation that Garmin epoch (used in FIT files and returned by certain CIQ API functions, contrary to docs and expectations) starts on January 1, 1990, which has been repeated more than once by more than one poster. It's actually Dec 31, 1989, but hey, what difference does one day make when you're working with dates, amirite?