I have a backend system for restaurants & food services. On the front end people are using a huge variety of measure units for recipes and such (kilo, cup, gallon, pint, small spoon, big spoon, pinch of salt, dash of pepper and so on). But i need to convert all that to something small and indivisible to make calculations, reports and analytics and the backend. However, to show some info and reports to the user i have to convert all the stuff backwards to the 'user-friendly' measure units.
Thus it can lead to errors in numbers (round-off errors and such).
What is the best practice to deal with that? Thank you!
Related
Let's say I have a strategy with multiple rules that generates multiple orders on the same symbol at the same timestamp. For example, on 2012-05-23 one rule might buy 10 shares of IBM while another rule sells 5 shares of IBM. In production, a reasonable system would use netting and execute one order to buy 5 shares, rather than one order to buy 10 shares and another order to sell 5 shares.
Is there a way to get this behaviour in quantstrat? From my experiments, quantstrat does not do netting, and for example will add transaction fees for both opposing orders as if two separate orders were executed.
If quantstrat cannot net orders then it should still be possible to obtain the desired PnL in backtesting by using a custom TxnFees function. If this is the correct way to go, how would one go about defining a custom function to net the transaction fees?
A 'reasonable system' would likely do no such thing. My experience of simultaneous execution on tick data is basically zero for aggressive orders.
On bar data, yes, internal netting would make sense, and would be handled by a production order management system. Or, for example, internalizing resting internal limit orders against other signals asking for aggressive orders on the other side, or netting positions. Does any investor of non-trivial size use bar data?
That seems to miss the point of what quantstrat is for. You are looking to figure out (in research) some strategy that makes good predictions and evaluate the quality of those predictions by writing a backtest.
Backtests aren't reality.
Further, netting would completely muddle any ability to figure out if your signal process has predictive power.
The account in blotter will net P&L automatically, so it will have the same result as your order netting, in the absence of fees. So I don't think you would need a separate TxnFees function to understand the possible impact of netting, pre-fees.
I'm looking for a language translation API/solution that would fit my use case.
My use case is the following:
The data is 1 GB of free unstructured text written mostly in the world's common languages (French, Spanish, German, Russian, Korean). The language of each piece of text is known.
We can assume the text is grammatically correct and consists of complete sentences, but contains some uncommon words such as chemical compound names.
The text has to be translated to English.
The solution must be at least 10x cheaper than Google Translate which charges $20 per 1M characters.
I would be willing to trade some of the Google's quality for cost-effectiveness. Google, Yahoo, Microsoft, Yandex, Online-Translator.com are all good enough, just too expensive.
I've got a 16 CPU machine at my disposal so offline translation is an option too.
Any suggestions?
For your volumes, Machine Translation prices range from $3 to $25 per 1M symbols (with some outliers like ModernMT which costs $eu per 1000 words).
If you want to trade off a little bit of quality, you may pick what we call "Optimal engines" - one which are within top 5% by performance but have the lowest price.
You may find more details in our Machine Translation report from July 2018.
Then, you need to know which engines support your language pairs and deal with their APIs, request limits and quotas.
You may use Intento API to get a list of engines for your language pairs.
Then, you may use this API in the async mode, then Intento takes care of all the limits. However I am not sure it will deal with 1G file, but you're welcome to try.
To avoid tinkering with the API requests, I would suggest using the CLI.
I run a monthly report which tracks session views by region, most popular knowledge articles, deflection rates, most popular product pages, software download stats, etc.
We have a new ELT member who is keen to get into the numbers around our contact centre. As I only look after the support site I need only concern myself with putting together a report which outlines what I feel will be useful information around web traffic. I want the report to be brief, and to highlight 4-5 key metrics.
Please can I have some suggestions for data you think would be useful given the target audience?
So far I am considering:
Deflection rates
Bounce rates.
Time on page
Most popular software downloads.
Global session views year to date.
Any help would be really appreciated. Thanks!
I think those metrics are great. Ideally, the value in the data comes from slicing your metrics with a dimension, ie pivoting. For example, bounce rate as an average means little whereas bounce rate by Content Group or Device Category would be more interesting.
Speaking of Device Category, consider completely isolating the metrics for Mobile vs Desktop+Tablet. Those experiences are so drastically different you'd be doing a disservice to average those metrics together.
Lastly, I'd say this new ETL member should get their own access to GA and learn how to pull the data need. GA now offers machine learning insights that quickly surface relevant drivers in metrics; a static approach to KPI reporting is becoming increasingly obsolete.
Is there a proper way, equation or technique in general to say, "My web application needs to support N number of total users which via this equation/technique/rockHardExperience tells me that I need to support X number of concurrent page requests"?
From my research and/or gut feeling it seems like it would be something like:
totalLoadCapabilityRequired = (totalUsersN x .10 ) * .5
where .10 is for roughly 10% on at any given time
and the whole thing multiplied by 50% to suggest a 50% chance of those total users online executing a request at roughly the same time
any insights would help me in making sure I implement support in my application that is on par for the demand. I expect a lot of users but don't want to over anticipate too early. I know for starters that the org I am programming for will have 45,000 users that they want to use my system, with an anticipation on success for many more.
Here's a couple of things to think about:
What's the time span in which you expect the bulk of your visits? If it's an office application within the same physical company your capacity planning should be based on an 8 hour period. If most visits will come from the same continent you can plan for a 12 hour period instead, etc. Base your visitor spread on that.
Which pages do you anticipate will be the most popular and how heavy are those pages (i.e. how many pages can you load in one second)? Get an understanding of parts that would benefit from caching to squeeze out more performance.
Don't plan based on peak load; design your app to scale and start small.
Design your app in a way that you can take run snapshots at every 500th request; you can use tools like xhprof to create files that you can run through cachegrind tools to analyze the performance as it runs.
In short, there's no catch-all formula :) for a ballpark figure your formula will probably be good enough, but take the above points in consideration.
i have been approached to build some websites for a few small businesses. They want a basic out of the box database driven website with some standard stuff (users, authentication, a few dynamic pages, etc). i am going to use asp.net mvc for this.
they have asked me how much i charge for this. my question, is that i have no frame of reference here. should i charge for the project a flat fee or a per hour charge. where do i start here to help determine correct pricing for a website project.
Charge an hourly fee that is about 3x the hourly rate you would command in a full-time job. The 3x multiplier basically evens things out for the benefits, etc. that you won't get as a 1099 employee.
Whatever you do, no matter how "Standard" it sounds. Do not charge a flat fee. Under that arrangement they have no incentive to curb feature creep. Even if you agree to a really tight spec up front, it is a recipe for disaster because it forces you to renegotiate every time they want something more. Under an hourly arrangement feature-creep works to your advantage.
Also, don't discount the hourly rate if you are a novice. Just don't bill unproductive hours. It is much easier to ease into billing more hours later than renegotiating the price per hour.
Charge per hour.
-- edit
So attempt to 'quote' it by estimating the number of hours. Make sure your estimate is conservative.
A nice approach is, in your head, consider the 'min', 'max', 'standard' type of time. Then use that to estimate the real time it will take you.
If you know that they know what they want and won't change the specs on you, go for a lump sum. That way you can work quickly.
If they are prone to change their minds and don't know what they want, go for an hourly fee. That way you won't be stuck working on their project for months without additional pay when they can't decide on exactly what they want.
I admit that I don't know much about this issue. However, I would still like to warn about the whole charge-per-hour mentality. While this approach basically protects the developer, it doesn't work well with the business owner:
Charge-per-hour, to the business owner, is a liability, whereas fix-price is just a cost. That's one.
The second thing is, if you are charging per hour, how are you going to justify your "research time"? Are you going to charge that as well? But business owner doesn't like to pay for research time. Or you can stick to your old trick and do something that has been reinvented N times and charge for the amount of time you spend. But that would seem unethical to some.
I have billed both by the hour and by the project. It's been my experience that customers are happier with project based billing instead of hourly billing.
With that in mind, I always pad the project cost by an amount I feel will cover the times when the client decides to change their mind. Further, I keep the project plan pretty simple. For example, I don't write 4 pages on how the login screen will work. Instead, It's a single bullet point: "Login Page". This allows both them and I a little flexibility.
Because I keep things simple AND I allow time for flexibility AND the clients know how much it's going to cost up front, my client's are happier and I can keep better track of my income. Also, I keep in pretty close contact with them. As long as you can keep the relationship good, you'll have a long term client.
Of course, it takes a bit of self discipline in combination with experience to know how long things take to build. Along these lines I never experiment on a client's dime. When I write the proposal, I already know what I'm going to use to get the job done and I've used those tools before. Because of this I can say with confidence that a login page will take a certain amount of time to put together.
Next, don't bite off more than you can chew. If it's a big project, break it up into smaller deliverables with their own pay schedule. That way the client (or you) can decide to walk away at any point. For example, if you think the project will take 3 months, break it up into 3 pieces. Incidentally, this helps with cash flow.
Finally, don't discount your time when getting started. That scares people.
I have a flat rate I charge for sites and outline exactly what they will get and then anything beyond that outline gets charged at an hourly rate. The hard part of this is if your getting into a project where your not sure how long it will take then you might want to break down the various pieces and then add at least 10 hours to that estimate. You don't want to sell yourself short but you also don't want to overcharge the customer. Be sure your clear up front that once the site is delivered then all changes are per hour or based on a maintenance fee structure.
Good luck.