2,711 karma · joined June 29, 2012
[ my public key: https://keybase.io/pamar; my proof: https://keybase.io/pamar/sigs/C2832FEsxtRdIvojiTUYs6V3pFvcW-ruh1CByYD47iM ]
If you are sure that 80% of your passengers will go to Hannover only to then fly to London (and back) your prices will reflect that... and Frankfurt-Hannover cannot be lowered too much because you still has to try to reach your quota for the flight per se.
Yield manager for that area/period has now the task to make sure he gets 112 or more on each ticket. And take in account that an unsold seat gets 0, so lowers the averge margin (which is what the yield is calculated upon).
This will soon make you realize that any chance to sell again a newly vacated seat is a boon.
So in the case of the OP the company can either assume that it was a honest mistake and he will somehow miracously get there in time to get on the second flight (3% chance?) or assume that he decided he does not care anymore, he had a serious accident, got fired, won the lottery, whatever (97%) and promptly put the seat back on sale.
The problem with a-b-c costing less than a-b is less obvious, maybe, but it has similar causes: for the airline it is more efficient to sell you the itinerary with a stopover so their pricing reflects that.
There have even been attempts to take passengers to court for getting off at the intermediate stop (they were dismissed) so it's definitely not just because the airlines are throwing a fit if you decide to change your plans.
Probably the a-b leg and the b-c legs sold alone are not very popular so they want more money to maximize the yield, while everyone wants to go a-c and return.
- Last minute travellers (who pay significantly higher for this)
- move their own personnel from B to A
- alleviating problems caused by overbooking, canceled flights, delayed flights or any other disruption.
Yes, it is not exactly the same thing but the point is: by getting off at B you are making the B->C flight travel with a wasted (empty) seat. Which they would have preferred to either sell to someone else or use for moving a pilot or technician to C.
(Note also that this trick of getting out mid-itinerary only works if you do not have checked baggage, because that will arrive in C, and neither the airline nor the airport will be happy to reroute it to wherever you thing you want to go next.
Flying is expensive and logistically complex. Just making sure you end up where your ticket say is complicated. If you (as a customer) decide to change your plans you are making everything more complicated (and possibly preventing other customers to pay for the whole itinerary).
My point was that to the layman this does not make any sense while if you are managing a shipping company you soon realize that some destination are more profitable because your truck that was maybe taking specialized replacements parts from A to B can easily pick up some other stuff to send back to A, while travelling in the opposite direction your truck has a high chance to travel empty on retutning to base... but you still have to pay the drivers, the fuel, the maintenance and possibly tolls.
Super-condensed version: civilian flight are a pretty difficult "product" to handle efficiently. Price increases until 1 minute before closing the airplane doors, then falls to zero. On top of that, the product "provider" also needs its own product in order to move personnel and technicians all over the globe, but of course they cannot just cannibalize their own products beyond the point of profitability.
Plus they have to handle rebookings and passenger protection in cases like delays, sudden airport close-down and so on. (Have you ever been on a waiting list, btw?).
All this is pretty complicated to manage already, so they need to exert as much control as possible on yield and occupancy.
TL;DR: a flight is not a bus ride. So if you just decide to cut it short the airline will try to reuse your vacant space for whatever reason.
Here is an example for you (from logistics): Sending a truck from Berlin to - say - Györ may cost 3 times less than sending the same truck from Györ to Berlin - even on the same exact date.
Is this because shipping companies try to make money out of nothing, for you?
Barcelona is not very Central, but weather here was perfectly normal so I'd like to hear different opinions.
I can now (probably, not sure if this exists) don my Apple VR set and walk around Machu Picchu or the Sistine Chapel.
But this would be a vicar experience. Just like reading lots of Wikipedia pages on, I dunno, Brutalism will not make an architect out of me.
Not sure about Gen Z and younger people though.
But then the post claims that "everything is a synchronization problem" seems should be qualified better.
Also, most of the comments before mine seemed to be in full agreement that yeah, full synchronization would be a silver bullet, even for cache invalidation
Example: you develop a web app to book for flights online.
My browser points to it and I login. Should synchronization start right now? Before I even input my departure point and date?
Ok, no. I write NYC -> BER, and a dep date.
Should I start synching now?
Let's say I do. Is this really more efficient than querying a webservice?
Ok, now all data are synched. Even potentially the ones for business class, even if I just need economy.
You kniw, I could always change my mind later. Or find out that on the day I need to travel no economy seats are available anymore.
Whatever. I have all the inventory data that I need. Raw.
Guess what? As a LH frequent flyer I get special treatment in terms of price. Not just for LH, but most Business Alliance airlines.
This logic is usually on the server, because airlines want maximum creativity and flexibility in handling inventory.
Should we just synch data and make the offer selection algorithm run on the webserver instead?
Let's say it does not matter... I have somehow in front of me all the options for my trip. So I call my wife to confirm she agrees with my choice. I explain her the alternatives... this takes 5 minutes.
In this period, 367 other people are buying/cancelling trips to Europe. So I either see my selection constantly change (yay! Synchronization!!!) or I press confirm, and if my choice is gine I get a warning message and I repeat my query.
Now add two elements: - airlines prefer not to show real numbers of available seats - they will usually send you a single digit from 1 to 9 or a "*" to mean "10 or more".
So just symching raw data and let the combinatorial engine work in the browser is not a very good idea.
Also, I see the pontential to easily mount DDOS attacks if every client is constantly being synchronized by copying high contention tables in RT.
What am I missing here?
Followed by test cases signature and then by user acceptance test documents.
This style could never work for me: "I'll push it to production on Day X, exactly as described here - unless you object" is not really applicable for me.
You can check this apparently paradoxical idea here: https://gwern.net/doc/borges/1951-borges-kafkaandhisprecurso...
(For the first part of your post I think I am not qualified to comment).
Btw, I notice only now that the link that was supposed to explain my question better is completely wrong.
https://news.ycombinator.com/item?id=42589014
(But you still provided much needed clarification).
I try to explain this a bit better here: https://pa-mar.net/Study/AiKiDo/VirtualBudoPass.html
I would like to "train" an LLM with a few thousand analysis documents that detail the various enhancements applied to a in-house app over the last twenty years.
My question is: some of the modules that are part of my app have been totally revamped, sometimes more of once. So while the general requirements for module Foo are more or less consistent, documents talking of it from 2005 to, say 2018 describes either bug fixes or small enhancements. In 2019 our main Foo provider completely changed their product and therefore the interface, so the 2 docs talking of Foo in 2019 are "more authoritative" than anything before that date... but then COVID happened so we have now Foo 3.0 which was implemented in late 2022 and is now being idly maintained with, again, small enhancements and fixes.
Documents have IDs which include an always increasing number (they start their life as Jira Issues)so just saying "newer=more accurate/valid/authoritative" could help, but I hope we do not need to rank/tag/grade every single document manually in order to assess how much weight it has on any specific topic.
Is this something that needs special treatment or will it just "work"?
Could you please provide some more info (or maybe links) about this, please?
(And I live in Germany since 2014 to boot)
I really think you are trying to draw conclusions about something that happens when learning most if not every language.
Example for English: https://www.gingersoftware.com/content/grammar-rules/adjecti...
In his opinion, the choice of colors was a consequence of poor light conditions inside ancient building. Not just because at night you had only oil lamps or similar sources, but because glass windows were not available either, so wall openings were smaller, and ofter protected by blinds or paper screens to mitigate the humid warm climate.
I suppose same applies to ancient buildings in other parts of the world, too.