Strange Compute() Interval Observation

DaveBrillhart said:

, but the 820 is about 20% too low. So it seemed (to me) like it was bogged down and I was betting compute() was being called about every 1.2 seconds on that device.

Just a nitpick here but this math isn't quite right. The inverse of "20% lower" is not "20% higher" (although a lot of people, including engineers, seem to think that it is.) In general, it's not the case that the opposite of X% lower is X% higher, although again, most people seem to think that it is. The only case where it's even close is 10%.

For example, if Bob gets a 20% discount on an item that Fred bought for regular price, it's not the case that Fred paid 20% more. (To see this, try the thought experiment with 50% or 100%.)

The correct math here would be 1 / .8 = 1.25. Yeah, I know you're not dealing with exact numbers here, but conceptually it's a very common mistake that I see all the time.

For example, say a mom and pop store owner wants to have a "no sales tax" day and say sales tax is 15%. To get rid of the tax, they'll manually give the customer a 15% discount at the register, but of course this means they're actually giving the customer more of a discount than they meant to, since .85 * 1.15 = 0.9775, not 1.The correct way to "undo" a 15% increase would be to multiply by 1 / 1.15 = ~0.8696.

Another example I've seen is where a *finance blogger* said that you should always negotiate a raise when you get hired for a new job. According to her, if she gets a 15% raise when she's hired, everyone else makes 15% less than her. Nope, that's not how it works.

DaveBrillhart said:

On my EDGE 1030, that interval varies every second (onUpdate() display refresh interval) between about 0.25 and 1.3. So it seems to imply that compute() is being executed between every 1/4 sec and 1.3 secs.... Does that even make sense?

I'll recheck my code and also now capture an average interval value. But the code is very straight forward so I don't know why it should show an interval time less and 1.0.

Without knowing anything else, I'd guess that the average interval will be roughly 1 second, and that the numbers you're seeing reflect a high variance (maybe due to other stuff going on.)

I and others have seen cases where a once-per-second data field update can be seemingly skipped completely under high load.

Thanks! That all makes sense. Yes a typo on the setValue() reference. I think the Telemetry Overlay developer needs to address this issue and detect stop time and reset metrics to zero during stop time.

FlowState said:

The only case where it's even close is 10%

This is not true. The lower the percent, the closer it will be, but never equal (except for 0%)

flocsy🤠 said:

This is not true. The lower the percent, the closer it will be, but never equal (except for 0%)

Sigh, yes you're right. Sorry, what I should've said is that the most commonly cited case I've seen where it's close is 10%.

It doesn't matter since the majority of ppl don't really care (including engineers I've worked with, which is slightly concerning *)

(* it was an informal discussion, where somebody said something along the lines of "X is 15% faster than Y, therefore Y is 15% slower than X". Sure, that discussion didn't matter, but how could anyone be sure that they didn't apply same reasoning when it did matter?)

What I‘ve seen with compute intensive datafields on Edge 1030:
on running and recording activities, the timer does not show continuous counting seconds, but skips up to 3 seconds per 10 seconds: 1,3,4,5,7,8,0….

I don't think they don't care about the numeric part, it's probably more that they don't care to explain it in 3 sentences what they mean. I mean if you see 2 items in a shop, one costs 80, the other costs 100 and you say one costs 20% more/less we all know what you mean. You could say one costs 25% more, the other 20% less, then people would look at you strange, then you would explain yourself, then they would say, ahhhh, sure, and then they would continue to look at you strange :) 

chose your words carefully, because if this is what's "shown" it can be because onUpdate isn't called every second. If you also see this in the fit file, and it is set from compute, then it's another story

flocsy🤠 said:

I don't think they don't care about the numeric part, it's probably more that they don't care to explain it in 3 sentences what they mean. I mean if you see 2 items in a shop, one costs 80, the other costs 100 and you say one costs 20% more/less we all know what you mean. You could say one costs 25% more, the other 20% less, then people would look at you strange, then you would explain yourself, then they would say, ahhhh, sure, and then they would continue to look at you strange :) 

I understand what you're saying here, and it probably applies in the case of the engineer and the informal discussion.

However, the fact that everyone *speaks* as though X% more is the inverse of X% less has real consequences imo, bc there are ppl who will take that literally, and there are many people who actually think that way. And this actually causes people to calculate things incorrectly, leading to real financial losses (however small).

flocsy🤠 said:

I mean if you see 2 items in a shop, one costs 80, the other costs 100 and you say one costs 20% more/less we all know what you mean. You could say one costs 25% more, the other 20% less, then people would look at you strange, then you would explain yourself, then they would say, ahhhh, sure, and then they would continue to look at you strange :) 

Take this to its logical extreme. Item A costs $10 and item B costs $20. So B costs 100% more than A, and A costs 100% less than B, right? Would anyone say that and be ok with it? Or is it somehow different bc everyone knows that a "100% discount" means you get the item for free? Or do the calculation the other way around. Now A costs 50% less than B, and B costs 50% more than A, right? Is there any other situation where you'd accept 2 wildly different answers for the same question?

Your example actually proves my point that most people actually don't understand percentages at all. The fact that they think (or speak as though) "x% more" is the opposite/inverse of "x% less" means they don't really understand (or stop to think about) what it means to "add x%" or "subtract x%". In your example, you would have to explain yourself if you gave the correct answer, right? Which means that these concepts don't come naturally at all to most.

The example I gave about a mom-and-pop store owner doing an incorrect calculation to reverse sales tax happened in real life. The owner ended up giving customers more of a discount than he intended, because of his inability to understand how to reverse an X% increase.

I would argue that even if some people "know" that what they're saying about percentages doesn't match reality, it's still a bad idea to say it that way, because it will confuse people who don't know better. That's why I dislike seeing this kind of thing from a finance blogger, for example.

The problem is that in English (and natural language in general), no normal person will say "the inverse of 15% more" (for example), and many people won't know how to calculate it anyway. Like you said, it's very awkward to express certain types of ideas about percentages precisely in natural language. If you could say "the inverse of 15% more" and have people actually understand what you mean, it would eliminate that problem, but that will never happen. People will just continue to say (and think) "15% less is the opposite of 15% more." Some ppl (but not everyone) will think in their head "well I said one thing, but I meant something else, because normies wouldn't understand or care if I explained it." I happen to think that's not a good thing, but there's nothing that can be done about it.

Also, having worked in retail, I can confidently say that most people don't understand percentages in general (not just this one case.)

For example, when I worked as cashier at a big box store, we'd have store-wide discounts that would "stack". e.g. 25% on top of 10%, applied consecutively. This was calculated as .9 * .75 = .675 (for a 32.5% discount.) No matter how many different ways we cashiers tried to explain it, it was impossible to get customers to stop asking us "where's my 35% discount??? 25 + 10 = 35!!!"

Customers would also ask us whether percentage discounts were applied before or after sales tax, not realizing it absolutely didn't matter. e.g. Item costs X dollars, discount = 10%, tax = 15%. "discount before tax" = x * .9 * .115 = "discount after tax" = x * .115 * .9.

Like sure, it probably mattered for legal / accounting reasons, but it absolutely did not matter for the purposes of the final amount the customer would pay - that would be the same either way.

Another example is how everyone knows that 50% more = 1.5X, 100% more = 2X, but somehow most people think that 500% more means 5X, and 1000% more means 10X (this happens in journalism all the time). Yeah, we can argue "everyone knows what you mean" or "the exact numbers don't matter", but what about the cases when the exact numbers do matter or when we *don't* know what you mean? If someone says "150% more", should I interpret that as "1.5X" or "2.5X"?

I also know people who don't understand how progressive income tax brackets work. They think that if you get a raise that moves you into the next bracket (with a higher rate), it's possible to actually take home less money than you did before the raise (not realizing that the higher rate in the next bracket is only applied to portion of income above the lower end of the bracket.)

I think that a lot of people are lot less math- and finance-literate than you think.

I also think that when we're discussing software development, precision is important, even if we "think" everyone knows what we mean. In these forums there's constant misunderstandings based on misinterpretations of an OP, or failure to even read an entire OP.

Again my reason for bringing up the percentage nitpick isn't that the exact numbers are important (they're not), it's that the implication regarding percentages is incorrect, and it's something that's pretty widespread.

I wanted to give the sneaky marketing example, but you just did that :) So yeah, unfortunately marketing heavily use these "tricks"

flocsy🤠 said:

I wanted to give the sneaky marketing example, but you just did that :) So yeah, unfortunately marketing heavily use these "tricks"

I mean we weren't trying to trick anyone. I think the only sane way to apply multiple percentage discounts is consecutively as described above (apply first discount to total amount, obtain 2nd total; apply 2nd discount to 2nd total, obtain 3rd total; etc.), as opposed to simply "adding up percentages".

Otherwise you could conceptually have stacked discounts that result in a negative price (e.g. a discount of "20% + 20% + 20% + 50%" would equal a "110% discount". 100% - 110%  = -10% which means we owe the customer money.)

The real problem isn't sneaky marketing, it's the lack of English / natural language tools to clearly and unambiguously communicate percentages (and other basic math concepts.) It's at the heart of all the examples I gave above.

Anyway thanks for coming to my TED Talk!

EDIT: there is a related case of sneaky marketing where the customer does get ripped off tho - mail-in rebate coupons.

- The customer pays full price and is charged tax on the full price

- When the customer mails in the coupon and gets the rebate, they're not refunded the tax difference, which means the rebate is worth less than advertised. That $50 mail-in rebate (no tax refund, so you still paid tax on the $50) is not the same as a $50 discount at the register (since tax would not be charged on the $50 you didn't pay.)

- This scheme also relies on the fact that a good percentage of customers (see what i did there) will forget to mail in the rebate coupon anyway