I try to formulate H.E. Dudeney's "loose cash" problem in AMPL/MathProg code.
Challenge the "loose cash" problem:
What is the largest sum of money-all in current coins and no silver
dollars-that I could have in my pocket without being able to give
change for a dollar, half dollar, quarter, dime, or nickel?
Problem my approach is incomplete:
set Coins;
param value{t in Coins};
var number{t in Coins}, integer, >=0;
subject to ...
maximize money_value: sum{t in Coins} number[t] * value[t];
data;
param: Coins: value :=
penny 1
nickel 5
dime 10
quarter 25
half 50;
end;
Question: How do I formulate the constraints section ... properly?
Related
I have a available amount and total amount and I want to check available amount < 30% of total amount, please let me know how can I calculate this
How I'd approach it, and this is really just math - so feel free to alter it as you need.
First, I'd find out what 30% of the total amount is;
var 30percentOfTotalAmount = (30 / 100) * totalAmount;
Then you'd just have a check against the available amount;
if(30percentOfTotalAmount <= availableAmount) {
// Do your logic
}
I'm trying to upgrade an application so that I can sell to multiple countries. I store all of my prices in the database in GBP excluding tax up to 4dp and I need to calculate the prices in the country's currency including tax.
Do I multiply the price by the exchange rate against the price excluding tax (option 1) or do I calculate the amount including tax and then multiple by the exchange rate (option 2)? I have also added an option 3 after looking at how OpenCart calculates it which is similar to option 2 but only ever rounds when displaying it. Here are the formula's for all 3 options:
Option 1:
Round((Price * Exchange Rate) / 100 * (100 + Tax Rate))
Option 2:
Round(Round(Price / 100 * (100 + Tax Rate)) * Exchange Rate)
Option 3:
Round((Price / 100 * (100 + Tax Rate)) * Exchange Rate)
For example say I have a product with a price of 89.99. If I wanted to display that in a currency with an exchange rate of 1.5 and a tax rate of 20%. Would I say:
Option 1:
Round((89.99 * 1.5) / 100 * (100 + 20)) = 161.98
Option 2:
Round(Round(89.99 / 100 * (100 + 20)) * 1.5) = 161.99
Option 3:
Round((89.99 / 100 * (100 + 20)) * 1.5) = 161.98
I've found that OpenCart always multiplies the unrounded figures by the exchange rate at the end. For example their formula for calculating the line total is:
Round((Price / 100 * (100 + Tax Rate)) * Quantity * Exchange Rate)
So if I was to order 3 of my product's it would give:
Round((89.99 / 100 * (100 + 20)) * 3 * 1.5) = 485.95
The problem I find doing it OpenCart's way is the user will see an item price (including tax) of 161.98 and a line total of 485.95. However if I say 161.98 * 3 I get 485.94, so it doesn't sum up correctly.
It's important I get this right as you can see I'll end up with penny issues. I'd appreciate it if someone could let me know which way is correct or suggest an alternative if none are right. Thanks
Since all variables are rounded except Exchange Rate, which I would expect to usually look something like this 1.3462, we can write a test like this:
// I'm guessing you need it in PHP
$price = 89.99;
$quantity = 1;
$tax = 20;
$tax = $tax/100.0 + 1;
// $tax = 1.2
$exchangeRate = 1.5;
$totalPrice = $price*$quantity*$tax; // Test #1
$totalPriceRounded = round($price*$quantity*$tax,2); // Test #2
echo $totalPrice.'<br/>'.$totalPriceRounded;
Which would have this output:
107.988 // Test #1 <--- This is amount that needs to be paid to you and Great Britain
107.99 // Test #2 <--- rounded
Now, it's obvious there is a difference in amount, so which to choose? Since you are charging an item from Great Britain, you expect to get paid the full amount you are asking for, in GBP, so lets rely on that factor. In the end, if I understood correctly, the tax the customer has to pay is tax to Great Britain.
Lets check the final prices in foreign currency:
$totalPrice = round($totalPrice * $exchangeRate,2);
$totalPriceRounded = round($totalPriceRounded * $exchangeRate,2);
echo $totalPrice.'<br/>'.$totalPriceRounded;
Which would have this output:
// Amount in foreign currency
161.98 // Test #1
161.99 // Test #2
With all that said, lets check which one of these would return you a value closest to 107.988 GBP when calculated back to GBP from foreign currency.
// To calculate the totalPrice back to price*tax*quantity in GBP
$totalPrice /= $exchangeRate;
$totalPriceRounded /= $exchangeRate;
echo $totalPrice.'<br/>'.$totalPriceRounded;
Output of which is:
// totalPrice in GBP currency
107.98666666667 // Test #1
107.99333333333 // Test #2
And when we divide by tax:
$totalPrice /= $tax;
$totalPriceRounded /= $tax;
echo $totalPrice.'<br/>'.$totalPriceRounded;
Output is:
// the amount you get in GBP currency
89.988888888889 // End result of Test #1
89.994444444444 // End result of Test #2
So as you can see, in this case, by using the bare amount of round($price*$quantity*$tax*$exchangeRate, 2) you are getting less, but by using round(round($price*$quantity*$tax,2)*$exchangeRate, 2) you get a little more which again, rounded both give the same value. In some other scenario the difference will likely be different from what we got here and might be the other way around.
CONCLUSION
If you have a fixed number of products each with fixed prices then you will be either loosing money (an insignificant amount) or earning more than you should (also an insignificant amount) over time. The outcome depends on the popularity and price of each product (i.e. will the round function round up or down), and on the way of calculation you chose. You could, depending on product popularity, manually adjust the prices of each product to minimize the loss/gain over time.
If you have products with random prices like lets say you are renting web servers and the price is $0.01/second. Then the expectation value for your loss/gain is close to zero. And the more purchases are made the closer to zero it gets. So you are not loosing anything here regardless of the approach. One time you win some one time you loose some.
In my opinion I would standardize it to round everything:
$price = 4.47;
$quantity = 1.2 // lets say liters
// Even round the price before applying tax
$totalPrice = round($price * $quantity, 2);
because if you are forced to show all the different stages of calculation then you will have to round every step.
But the most precise would be to use this as the least information is lost:
// Round once at end
$totalPrice = round($price*$quantity*$tax*$exchangeRate, 2);
In the end it all depends on how you set up your product prices or how your pricing works to be able to choose which method to go with. I'd say it doesn't really matter, I think every company simply chooses what suits them best.
Legally, some countries/cities/etc. have laws on how to calculate this, you should be looking at Great Britain laws to check on the valid procedure for your problem.
I can't tell you what the correct option is or even if there is one correct option. But from experience I can say, if there are multiple options to do one thing, make it configurable in your software. In this case you can easily use the strategy pattern and make the strategy for calculating prices configurable. Customers can choose how they want it calculated.
The correct solution depends on your business. When you sell items in different countries, you most likely have branches in those countries - and you need a net price in those country's currency. This results in the net price per item "translated" to the foreign currency, and this net price is then multiplied with the amount and multiplied with the tax factor/percentage).
The EU MOSS (which is charged when you offer services in other countries, or e.g. software as download) is somehow different. You can sell products with GBP pricing, but have to consider your consumer's local tax factor. See e.g. https://ec.europa.eu/taxation_customs/sites/taxation/files/resources/documents/taxation/vat/how_vat_works/telecom/one-stop-shop-guidelines_en.pdf
For MOSS, I didn't check in detail, but I expect that you then have a different formula, using your local GBP net price per item, multiply with amount, multiply with consumer's tax percentage. This tax amount, still in GBP, should then be multiplied with currency exchange rate, I'd expect.
I'm trying to select a random row from a table, but there is a column in this table called Rate, I want it to return the row that has a higher rate, and rarely ever return the rows that has a lower rate, is this possible?
Table :
CREATE TABLE _Random (Code varchar(128), Rate tinyint)
So you want a random row, but weighted towards the ones with higher rates?
It would also be good to know how many rows there are in the table - sorting the whole lot is kinda expensive. You may prefer to use a row_number concept than sorting by N guids.
So... One option could be to generate a single number, and then divide 100 by it. Imagine we generate a number between 0 and 1.
.25 gives us 400, .5 gives us 200, .75 gives us 133... Notice that there's a curve here - so the numbers closer to 100 come up more often (subtract 100 to make the range start at 1).
You could use RAND() for a single value between 0 and 1 (it's probably good enough), and then do the division and subtraction to get a number. If this is higher than the count of records, then maybe repeat? But try to choose a value for your division that suits.
If you need to weight it more, you could raise your RAND() value by some number, to flatten it out or steepen it up. Do some experimenting to see how it looks.
This query will fetch a random record which has an above average rate
SELECT TOP (1) * FROM _Random
WHERE Rate>(SELECT AVG(Rate) FROM _Random)
ORDER BY NEWID()
I'm building a function to return the net value of a sales invoice once any purchase invoices marked against it have been taken off - part of these costs are contractor costs of which we also want to calculate either NI or a set increase to the contractor pay to reflect "true" value.
So on one sales invoice, we may have several contractors where we have purchase invoices against it, some may be at NI calculated at 13.8%, others may be at a standard "uplift" of 10% and others may be at 0% added.
The bit that I'm trying to figure out is if I need to make the whole function as a cursor as there are going to be different figures for a variable for each purchase invoice
e.g.
(SELECT SUM(th.hoursworked * (th.payrate * (1 + (#NIAMOUNT / 100))) )
but the #NIAMOUNT will have to change for each purchase invoice.
Is the best way of doing this via a cursor, or is there a better way of doing this?
Sorry if this is a bit verbose!
You should avoid cursors wherever possible - cursors operate 'serially' which will limit SQL's performance.
If the calculation is simple, one way to do this would be do do the NI lookup inline, e.g.
(SELECT SUM(th.hoursworked * (th.payrate * (1 +
((CASE somejoinedtable.UpliftType
WHEN 1 THEN 10
WHEN 2 THEN 13.8
WHEN 3 THEN 0
END
/ 100))))
If this becomes too messy to do inline, you could abstract a user defined function
CREATE FUNCTION dbo.fnGetNIAmount(int #someLookupParam)
...
And then do like so
(SELECT SUM(th.hoursworked * (th.payrate * (1 +
((dbo.fnGetNIAmount(somejoinedtable.UpliftType )
/ 100))))
You almost certainly don't need a cursor
Join your hours worked to the contract they are based on, and take the NI value from the contract.
I have an array of dictionaries. Each dictionary holds data about an individual audio track. My app uses a star rating system so users can rate track 1-5 stars. Each dictionary has its own rating data per track, as follows:
avgRating (ex: 4.6)
rating_5_count (integer representing how many 5-star ratings a track received)
rating_4_count
rating_3_count
rating_2_count
rating_1_count
I'm trying to create a Top Charts table in my app. I'm creating a new array with objects sorted by avgRating. I understand how to sort the objects using NSSortDescriptors, but here is where I'm running into trouble...
If I only use avgRating as a sort descriptor, then if a track only receives one 5-star rating, it will jump to the top of the charts and beat out a track that might have a 4.9 with hundreds of votes.
I could set a minimum vote count to prevent this in the Top Charts array, but I would rather not do this. I would then have to change the min vote count as I get more users.
This is a bit subjective, but does anyone have any other suggestions on how to effectively sort the array?
There is many ways to deal with such a situation.
One approach could be to consider the number of votes as a measure of the confidence in the rating average. Starts with an average set at 3 (per example).
const double baseConfidenceRating = 3;
NSUInteger averageRating = ...;
NSUInteger voteCount = ...;
const NSUInteger baseConfidence = log10( 1000 );
double confidence = log10( 1 + voteCount ) / baseConfidence;
double confidenceWeight = fmin( confidence, 1.0 );
double confidenceRating = (1.0 - confidenceWeight) * baseConfidenceRating + confidenceWeight * averageRating;
Now sort your array based on confidenceRating instead of averageRating.
You can tweak the algorithm above by changing how many votes are needed so confidenceRating equals averageRating, and of course, you can change the function I used in the example. square root could work as well, or why not a linear progression. Your call.
This is just an example of course, a pretty dumb one. The standard deviation of the votes may add some intelligence in the algorithm, taking not only the number of votes into account but also the distribution of votes. 100 votes on 100 at 5 have more 'confidence' than 1000 votes scattered randomly between 0 and 5. Methink.
Yes, add a method to your class that returns a weight calculated from the average and number of votes. The magic formula for the weight is up to you, obviously. Something like avgRating * log2 (2 + number_of_votes) might do it. Then use a single sort descriptor that sorts on this method.