Overall I think it's good that we now have a pretty direct way to pay upfront for increased convenience of faster delivery time. This value is akin to the (opportunity) cost of actually going out to physically buy something if you want/need it almost immediately but starting to increase the market of goods beyond just that you can get in local shops.
Minor niggle: They mention the Amazon Prime Now $8 fee for one hour delivery but neglect to mention there is no additional fee for delivery within only two hours. There is of course the recommended "tip" which sits at around 10%, but for a fairer comparison with the other mentioned services generally providing delivery within a day, I think the free option within two hours is more comparable.
Overall I think it's good that we now have a pretty direct way to pay upfront for increased convenience of faster delivery time. This value is akin to the (opportunity) cost of actually going out to physically buy something if you want/need it almost immediately but starting to increase the market of goods beyond just that you can get in local shops.
Minor niggle: They mention the Amazon Prime Now $8 fee for one hour delivery but neglect to mention there is no additional fee for delivery within only two hours. There is of course the recommended "tip" which sits at around 10%, but for a fairer comparison with the other mentioned services generally providing delivery within a day, I think the free option within two hours is more comparable.
This is the current system, but with "use this physical item, the SIM card, to login".
This does assumes that the replacement phone in question is unlocked so can work on the other SIM card, but is certainly something that many people do quite often.
Another scenario where this causes issues that a login equivalent can improve: imagine losing your phone including SIM card. This then causes a full interruption of all services tied to that phone number including actual phone service, and SMS, until the SIM is replaced. This usually takes hours/days depending on your location or carrier.
The other big difference in just swapping out sim cards is the need for a full phone reset and the interruption to the service of whomever you're borrowing the phone!
Yep, essentially lots of 'not quites' with the current system.
I want phone-as-easy-as-email. I logon and immediately calls are routed to that device and I can pick up voicemail, make calls and send texts. If I have another phone account I can use the same handset to log into that account at the same time and all calls to that number get routed to the device as well. If the device has radio hardware (such as phone handset) it uses the radio network otherwise it uses wifi or whatever other network comms that device has. When I logout it all stops.
As a customer that's the interface to 'phone' that I want. Phone is soft, not hard.
Imagine 2.9 Billion phones with a login of 'password'.
SIMs are secure(ish). Hand typed passwords are not (no one want to memorize and type a 20 character password formed from a mix of upper/lower/numbers/symbols).
(yes, sims are hacked and cost carriers billions. hacking sw passwords is a lot easier).
Kobo evidently are doing some analysis on completion rates, and published a report last year aimed at publishers using analysis based on similar metrics:
Nice find. Yes raw data will be more useful. Especially, with Amazon's Pay-Per-Page for Kindle Unlimited, if such data is available, it will be interesting to see how authors reverse engineer this process to achieve maximum page views (and completion rates)
This really would be interesting. I'd like to see data on overall completion % for ebooks. Assessing those books which tend to be completed once started would help identify the more interesting books.
Combined with top selling book lists, this would provide a good filter to decide on potential new reads and could form the heart of improved book recommendation services.
Primary compliments I also have in particular for the author is inclusion of a link to source code and the concise but complete and informative "tools used section" describing the process. I wish more analysis (particularly those presented on more reputable news outlets) was presented with a similar section for reproducibility and exposure to analysis techniques.
I also imagined floating point arithmetic problems when seeing the title. What is really happening here is that a, b and c may themselves have different values depending on the operation - as adding a month here isn't a fixed number of days as month lengths differ.
The article states it perfectly at the end though: "When doing math that deals with time, specifically different units of time, it can lead to unexpected results if you are not careful with the ordering". I think this can generally be extended to "when doing any math that deals with time, it can lead to unexpected results if you are not careful with everything"!
> "When doing math that deals with time, specifically different units of time, it can lead to unexpected results if you are not careful with the ordering"
Not arguing with you, but with the poster: I think that a deeper lesson might be the important realisation that, unlike 'day' or 'hour', 'month' is not a unit of time! (At least, not any more than 'moment' is. (I know, I know, https://en.wikipedia.org/wiki/Moment_(time), but you know what I mean.))
> unlike 'day' or 'hour', 'month' is not a unit of time!
Not a 'fixed unit' of time. Where I define 'fixed' as being always of the same size (like gram or meter).
My next thought is that day is also not fixed in case of daylight saving and leap seconds. A day has many definitions: astronomical, 24 hours, calendar, etc.
Maybe we can also see this problem with 'hour'; but in that case it would be more contrived.
Bottom line: programming time is hard, be aware of that.
I think that it's fair to say that even, or perhaps especially, the most obvious concepts, when sufficiently well understood, exhibit subtleties. (I always tell students in my mathematics classes that the correct answer to every question is "it depends", and, though it's somewhat facetious, I honestly can't think of a mathematical statement so basic and obvious that a sufficiently sophisticated mathematician couldn't correctly raise this objection.)
With that said, while I agree that there may be different colloquial definitions of 'day' and, as you mention, of 'hour', and even of 'second' (https://en.wikipedia.org/wiki/Second#Other_current_definitio...), they also have unambiguous scientific definitions that can be pinned down by sufficiently precise reference; whereas 'month' simply does not.
EDIT: I should clarify that I'm not attempting by any of this to say that programming with times isn't hard—it absolutely is. I just think that a large part of it can be traced to confusion about what is not a unit (which, as observed by cies above (https://news.ycombinator.com/item?id=9665366) and DannoHung below (https://news.ycombinator.com/item?id=9665472), can include such seemingly innocuous concepts as 'day'), and that it might be profitable explicitly to state this unifying idea as one way to guide attempts to program successfully with time.
I wouldn't trust any time unit larger than seconds if I was concerned about my units staying consistent. Hopefully time-keeping bodies don't decide we need leap-millis at some point.
Which is only to say that this is a problem that can't be solved simply by discarding some concepts that you find problematic. There's a lot of shit about timekeeping that's problematic. I'd advise tossing all the problematic shit when trying to figure out some internal representation for the underlying time that more or less always makes sense and then building out more human-usable representations with the uglyness on top of it.
> Which is only to say that this is a problem that can't be solved simply by discarding some concepts that you find problematic.
> I'd advise tossing all the problematic shit when trying to figure out some internal representation for the underlying time that more or less always makes sense and then building out more human-usable representations with the uglyness on top of it.
I don't mean to be snarky, but these two sentences seem contradictory—you say that the problem can't be solved by discarding problematic concepts, then advise to discard problematic concepts. Are you making the point that, even if internally we work with an un-problematic representation of time (if such a thing exists!), at some point we have to convert to and fro? Certainly I agree with that. Though I seem to have said it badly, that's really what I meant to say above: trying to work directly with months (and, perhaps less dramatically, with days), which are not units of time, allows the problematic real-world notion of time to contaminate what should be the clean internal representation of it.
I guess? I'm saying that you can't realistically avoid working with the problematic units. Like, if you want to have a monthly payment system, at some point, you have to bake in the human concept of months into your system, warts and all.
When my cell plan was with T-mobile, I was on a pre-paid plan. My bill was due once a month, so I set up monthly automatic billing. Well, the system that enabled or disabled my service depending on if I had paid considered that to be "every 30 days". The system that handled the automatic payments considered that to be the same day every month (IIRC, it charged my card on the 18th of every month; when I set it up my bill was due on the 20th). A couple of 31-day months later, and I lose service for a day because the automatic payments didn't keep up with the bill being due.
Or more accurately, "Doing math that deals with different units of time will inevitably lead to unexpected results."
If you gather 6 different company executives and business requirement authors and ask them all to explain what it means to be "one month and 5 days later" than a given date, I guarantee you will get at least 3 or 4 different answers. No matter WHAT your code implements, it will be unexpected to some users.
As a developer, when I encounter a requirement like this one I feel it is my duty to push back on the requirement. I won't ACCEPT a requirement like "the grace period is a month and five days", and will instead (try to) force those writing the requirements to specify something clear like "the grace period is 35 days" or "the grace period is until 5 days after the same same date in the following month" (still somewhat misleading).
I have been working in software development within big business (banks, mostly) for quite some time now, and I frequently observe that developers -- probably because of the nature of their job -- tend to be good at thinking of something clearly and precisely, while those writing requirements tend to be fuzzy on the specifics but better able to understand the overall picture. Working at the interface between the two, my job is often to get each side to step up to the level of the other.
The same approach is in legal issues. Words "a month and a five days" shouldn't ever get past a lawyer, you'd get "35 calendar days" or more likely something like "25 business days as defined by XXX; if the notice is submitted past 18:00 then it's treated as if submitted on the next business day"
> What is really happening here is that a, b and c may themselves have different values depending on the operation - as adding a month here isn't a fixed number of days as month lengths differ.
spot on; very much a human mistake, a false assumption of how things work.
> The article states it perfectly at the end though: "When doing math that deals with time, specifically different units of time, it can lead to unexpected results if you are not careful with the ordering". I think this can generally be extended to "when doing any math that deals with time, it can lead to unexpected results if you are not careful with everything"!
Another idea: don't dress up things that don't have anything to do with conventional math as conventional math. Using operands who's value depends on the value of the expression evaluation up to this point (I'm guessing left to right) is an aberration.
