Function for recommendation of products depending on likes [on hold] - python

I have a set of different products which all have a different number of likes. Also each hour new products could be created. The goal is to be able to put first the products which have the highest number of likes but also give a chance to the new products.
So for now, I have two variable for each product : Number of votes and time spent since creation. My current function which give a weight to each product is :
(1 + nb_vote) / nb_hours
Does someone have a better function to propose ?


Forecast of order quantity for products

I have dataframe as below.
Product_family: Products ; Trunc( Date when the product order came; Warehouse: Which state it belongs to; Ordered_qty: how many orders are placed.
Based on that data I want to predict forecast of order quantity for a particular product based on product.
Here the challenge is, I want to calculate all order quantities that are created for a particular product in a month.
Example: Lets say 1600 product orders are 48 in a particular month(2017-09-01 to 2017-09-30) is what i want to calculate.
Similarly do for all products(120+ products in my data). Then group them based on month and then predict the future order_qty for a particular month.
So, my prediction output should be how many orders are going to come when i input product id and date- [month(2018-03-01 to 2018-03-30)] and warehouse.
I am new to python and Machine learning. I know it is a regression model. please suggest me approach to follow and how to group all data based on month and products and pass the data to model.

Application overhead design decision: store needed value on database row or find it dynamically in queryset

I'm developing a simple price tracker application. I'm a bit new to web application design and could use an experienced opinion here. My application pulls price points for hundreds of thousand of products per day by unique product SKU.
For each SKU I want to be able to show:
All time high price
All time low price
Average price
When my API writes a new SKU price to the database I am able to figure out these three values and write them to the latest/current price row. Is this a better design decision than say using a Django Queryset in my View to query for and/or calculate and display them?
Sure, I'm currently feeding them to a Django Class Based View with def get_context_data.
context['high_price'] = prices.order_by('price').last()
context['low_price'] = prices.order_by('-price').last()
context['avg_price'] = prices.aggregate(average=Avg('price'))
Note that I am not using aggregate MIN/MAX as I need the date with each price as well so I need to entire price row (Price model is structured in columns of 'Date of Price' and 'Price').
Original question still stands. Should I Queryset this or write the high/low/average each time I bring in a new price? Here's how I could do that (example for highest all time price):
if product.high_price is None or (price.value is not None and price.value >= product.high_price.value):
product.high_price = price
Using a queryset for this should be fast, provided you have an index. It would be interesting to benchmark what you have, then in your model, add index and repeat. eg.
price = models.DecimalField(db_index=True)
Calculating the average will be the slow one and it might be worth have a job that calculates the average and stores it somewhere. You can use celery/redis to do this in the background or do it once when you pull the data in, depending on your setup.

Defining/algorithm, python

Recently I started to learn python.
There was a need for the program.
Please point the track :
The program takes two values from a file: the enterprise and the number of people in them.
Next i need to make the following calculating : finding company with the fewest people - > define it as one part of all - > count ratio is less than all other companies - > count of the number of rations for some time, uniformly.
First, I don't know, what i need to do first. Should i define all data like this "Company = numbers", or do a dict?
I don't ask to solve the problem - I ask to teach.
for your example if you want to keep it as easy as possible put all your data in dicts you don't need to create database or file to store the data, for each entity you have to create its variable as dict and make the relationship between them with id like this : we assume that we have client and orders entities:
client = {
and so on.

Python - Pick from Array based on price with a caveat

I'm relatively new to Python and have already written a code to randomly select from two tables based on user input but the next function I need to create is more complex and I'm having trouble wrapping my head around.
I'm going to have some code that's going to take user input and generate an amount of money I'm going to add to a variable, lets say, wallet.
I then want to write some code that takes random objects from an array based on price.
Now here's the caveat(s). Lets say array A is chosen. In Array A there will be 3-4 other sub arrays. Within those arrays are 4 objects first, second, third, and fourth. With the first being the cheapest and the fourth being the most expensive. I want this code to NOT be able to buy object second without having bought object first. I don't want an object purchasable unless the prerequisite is also purchased.
I'm just having a hard time thinking it through (a weakness in general in programming I need to overcome) but any advice or links to a concept similar to what I'm aiming to do would be greatly appreciated. Thanks!
From your description, it might be enough to have a counter associated with each sub-array as to how many of the items in that sub-array have already been bought. Give that you haven't shown any details as to your representation of these things, I can't give more details as to how to implement this.
It's difficult to understand what you're getting at, because you're not expressing your ideas very well. You're finding this general programming difficult as programming can be considered as the precise expression of ideas.
So, in very general terms you are trying to simulate some sort of curated shopping experience. You need to:
Track a value of currency.
Manage a product catalogue.
Allow a selection of products based on value and constraints based on prior selections.
If I were doing this, I might write a class that I'd use to manage the basket. I might instantiate a basket with a budget figure and a product catalogue to select from. I might express the constraints in the catalogue, but enforce them in the basket.
I would probably use the basket (budget, tally and selections) to filter the product catalogue to highlight eligible products.
If multiple transactions are allowed, the basket would need to have knowledge of previous purchases and therefore which prerequisites have already been fulfilled.
def can_buy(wanted, for_sale, bought):
return (wanted in for_sale and
wanted not in bought and
wanted == for_sale[len(bought)] and
bought == for_sale[:len(bought)])
You can use it like:
>>> for_sale = [1, 2, 3, 4]
>>> bought = [1, 2]
>>> can_buy(3, for_sale, bought)
>>> can_buy(4, for_sale, bought)

ASP.NET calculated properties on object, should be in db or calculated runtime?

I have a small webshop-like web application, and i have big plans :-)
I have a basket object and a basketitem object, the basket has a list of basketitems. At runtime i dont have the list, it has to be loaded from database (using a repository pattern) with the id of the basket. The basket can exist for several days (max 30 days) and the customer can add basketItems to the basket during this interval.
What is the best approach to calculating the total (i have several similar calculations to make) of the basket, should i maintain a field in the database and update it when i add something to the basket or should i calculate it on the fly as a property (for databinding purposes)?
Lets say I have to make two calculations on this basket, one for the total, and one with a discount (tricky algorithm, dependent on many variables).
How about 3, 4 or 5 calculations, which is the best approach?
I would calculate the total on the fly - if the price of any of the individual items change whilst they are in a customer basket, then I would imagine that you would want to sell them at the new price if the prices have gone up or would want to pass any savings on to the customer if they have gone down :)
If you're storing it in a database, it's redundant data - you have all of the data that you need to calculate it already stored against the individual items. It also means that you would need to update that database table/field each time the user logs in to update the total.
This should not be stored in the database since the purchase hasnt been completed yet. Any product within the basket may have changed price during the time when the item was added, and you calculate the total amount.
Same goes for discounts, some are time limited and need to be reevaluated.
Such calculations, especially if they are subject to frequent changes are best calculated on the fly.
Otherwise, you will end up with having to update these database fields for all existing baskets, over and over again.
I would use a combined approach, calculating prices on the fly for items in the shopping basket, then storing all calculated values later on, when the items have been paid for. This way I'd have the benefit of allowing price changes and discounts for products while skipping the calculations when a client visits her previous orders.