I understand that an object can have only one finite state at a time. A telephone has few different states like ringing, hold, talking etc... An alarm clock has states like ringing, not ringing etc...
I'm looking at an abstract class like Product which can have different statuses like sellable/non-sellable, taxable/non-taxable, tangible/in-tangible. When any of these statuses change for a Product, it will trigger some behaviors in the system.
Should I consider the statuses of a generic class be states? Can a Product keep different states and can still be considered as FSM?
I am sure there is no single right answer here. But I would say it depends. If you want to consider the whole Product a single FSM, then your state would be a sum of all the attributes. Such as sellable, taxable, tangible, ... At one point it might be sellable, taxable and tangible. If the tangible became non-tangible, it would then be sellable, taxable and non-tangible.
On the other hand, if you view your product from the viewpoint of a specific function, you might take a subset of these to represent the product. So, a sales function might just consider the sellable state. A tax function might just consider taxable.
Anyway, like I said, I think depends. On your use case for the FSM and on whatever you want to accomplish. In the end it is just some terminology unless you need the FSM for something special..
Related
When creating a HKWorkoutSession we need to provide a HKWorkoutConfiguration with a HKWorkoutActivityType.
There are many HKWorkoutActivityType available to use, but I don't find what is the application of it.
Does different type of activityType contribute different amount of totalEnergyBurned during the workout? or is it only used in querying the HealthKit for particular type of workout?
I am creating a general workout watchApp by which a user can just start and stop a workout to complete its rings. But I am confused by HKWorkoutActivityType. Will there be any difference in TotalEnergyBurned if I use different HKWorkoutActivityType, because it is contributing to close the red ring.
As far as I can tell, HealthKit needs to know the HKWorkoutActivityType so that the workout is listed properly in Apple Health. It does not automatically calculate the totalEnergyBurned or any other quantities used to characterize the workout:
Your app should always provide data for the workout’s duration,
totalDistance, and totalEnergyBurned properties when the data is both
available and relevant to the workout. In addition, you should provide
a set of associated samples that sum up to these totals.
From: https://developer.apple.com/documentation/healthkit/hkworkout
I do not know whether HealthKit validates whether a quantity is appropriate for a given type of workout, e.g. wheelchair "pushes" when swimming.
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.
Im learning dimensional modeling and Im trying to create a model. I was thinking about a social media platform which rates hotels. The platform has following data:
hotel information: name and address
a user can rate hotels (1-5 points)
a user can write comments
platform stores the date of the comments
hotel can answer via comment and it stores the date of it
the platform stores the total number of each rating level (i.e.: all rates with 1 point, all rates with 2 point etc.)
platform stores information of the user: sex, name, total number of votes he/she made and address
First, I tried to define which information belongs to a dimension or fact table
(here I also checked which one is additive/semi additive/non-additive)
I realized my example is kind of difficult, because it’s hard to decide if it belongs to a fact table or dimension.
I would like to hear some advice. Would someone agree with my model?
This is how I would model it:
Hotel information -> hotel dimension
User rating -> additive fact – because I can aggregate them with all dimensions
User comment -> semi additive? – because I can aggregate them with the date dimension (I don’t know if my argument is correct, but I know I would have new comments every day, which is for me a reason to store it in a fact table
Answer as comment -> same handling like with the user comments
Date of comment-> dimension
Total Number of all votes (1/2/3/4/5) -> semi-additive facts – makes no sense to aggregate them, since its already total but I would get the average
User information sex and name, address -> user-dimension
User Information: total number of votes -> could be dimension or fact. It depends how often it changes. If it changes often, I store it in a fact. If its not that often, then dimension
I still have question, hope someone can help me:
My Question: should I create two date dimensions, or can I store both information in one date dimension?
2nd Question: each user and hotel just have one address. Are there arguments, to separate the address dimension in a own hierarchy? Can I create a 1:1 relationship to a user dimension and address dimension?
For your model, it looks well considered, but here are some thoughts:
User comment (and answers to comments): they are an event to be captured (with new ones each day, as you mention) so are factual, with dimensionality of the commenter, type of comment, date, and the measure is at least a 'count' which is additive. But you don't want to store big text in a fact so you would put that in a dimension by itself which is 1:1 with the fact, for situations where you need to query on the comment itself.
Total Number of all votes (1/2/3/4/5) are, as you say, already aggregates, mostly for performance. Totals should be easy from the raw data itself so maybe not worthwhile to store them at all. You might also consider updating the hotel dimension with columns (hotel A has 5 '1' votes and 4 '2' votes) that you'd update as you go on, for easy filtering and categorisation.
User Information: total number of votes: it is factual information about a user (dimension) and it depends on whether you always just want to 'find it out' about a person or whether you are likely to use it to filter other information (i.e. show me all reviews for users who have made 10-20 votes). In that case you might store the total in the user dimension (and/or a banding, like 'number of reviews range' with 10-20, 20-30). You can update dimensions often if you need to, but you're right, it could still just live as a fact only.
As for date dimensions, if the 'grain' is 'day' then you only need one dimension, that you refer to from multiple facts.
As for addresses, you're right that there are arguments on both sides! Many people separate addresses into their own dimension, referred to from the other dimensions that use them. Kimball suggests you can do that behind the scenes if necessary, but prefers for each dimension to have its own set of address columns(but modelled as consistently as possible).
I'm sorry if this is not within the acceptable question guidelines for Stack Overflow, but I am feeling stumped, and I feel that what I'm trying to do might just be incredibly simple for some of the veterans here.
I've set up an Ubercart on a Drupal installation for a small gym website. What they are wanting is to allow a customer to register and pay for various memberships for their children (youth flag football, teeball, etc.). One person may come back and sign up multiple times throughout the year, and each customer may have multiple children who can each participate in multiple programs.
What I'm thinking is to disable anonymous checkout on Ubercart. The customer billing address will be the saved information for the "parent." I'm thinking that the parents could create Members (their children) which could be stored in a content type called Members and the Members could be linked to the programs of which they are a member via entity reference. The children could maintain their relationship to their parents by authorship.
I've been trying to work through this for the last few hours. Does anyone know of a way the I can accomplish this--maybe with rules? I'm thinking some kind of credit system in which for each quantity of a membership (per program) that they pay for, they get one "credit" to create one entity reference between a member and a program.
Any brainstorming and help on this topic would be majorly appreciated. Thanks.
Your use case sounds more like event registration than selling memberships. Each class would be an event that parents would register their children for. It may seem like overkill here, but I would use something like CiviCRM or RedHen CRM for this. Both support the concept of relationships between members and provide event management tools. You could make each class an event that people would sign up for, pay (they could even register multiple children at the same time) and get a receipt. The event history information would be stored so parents could sign in and see what each child has done. You could even make the list of kids in the class public so parents could see who else is in the class.
Afterward, it would be easy to put together a survey to send to the "attendees" to get feedback on the event/class and notify them about future events. I can think of a dozen different things that these systems cover that you may need in the future (early bird event registration, special pricing for returning parents/children, activity reports to email to parents every year so they can see what their children did...).
You may be able to pull together modules and custom content types (Ubercart Event Registration module as a starting point), but a CRM would provide the things you are looking for now, and the features your customer will be asking for in the future.
I have two database tables
this is a sample database of a Ticketing system.
Figure 1: Sample table of air ticket.
Figure 2: Sample table of tax.
Requirement:
When ticket is made from the interface, it has multiple taxes of different names every time.
How can I store this information i.e. 'n' number of taxes for each ticket with different names every time.
I have tried to make many to many relationship but the problem is:
For each ticket if the tax is not setup, then need to add the tax first.
Any optimal solution for this?
"the problem is: For each ticket if the tax is not setup, then need to
add the tax first."
This is not a real-life problem. In real life governments declare taxes well in advance of collecting them, This gives organizations sufficient time to amend their systems which need to handle taxes. Tax is never a surprise.
"But this is very tiring solution for the end user.... to make bunch
of tax setup for each ticket"
This sort of thing is reference data, and is the duty of the system developer (hint: that's you) to populate the reference data tables. Or at least provide a screen where the user can create or amend various taxes. This is a different function from defining a ticket type.
The Ticket Creation screen should have a drop-down list (or similar widget) displaying all the existing taxes, which allows the user to pick the relevant one(s). If you reall think it's necessary you can include a link to the Create Tax screen, but that really is a very confusing workflow.
If the commentators are correct, and this is a ticket purchasing function, then your design is seriously wrong. Sales taxes must be included automatically to the cost of the purcahse as part of the transaction. Otherwise nobody would pay any tax.