I'm using Brickficiency 2.01a and I noticed that BrickLink actually found a better solution than Brickficiency, even when the latter computed all combinations. The reason is that Brickficiency only uses 2 decimal digits for the part price, whereas BrickLink uses at least 3. After multiplying that price with the part quantity BrickLink then rounds the lot subtotal to 2 decimal digits.
So if a part costs $ 0.016 and you order 1000, BrickLink will compute the lot subtotal to $16, whereas Brickficiency will compute it to $20. (And FWIW the rounding appears to goe the other way, too.)
Here is the example, where BrickLink finds a better result:
Here is one position from the Brickficiency result file:
And the same position in the BrickLink shopping cart:
Of course the error is small, in my case less than a percent of the amount, but could be a few percent in some cases. Still every penny counts, so it would be nice, if Brickficiency could use the same number of digits for the part price as BrickLink.
I'm using Brickficiency 2.01a and I noticed that BrickLink actually found a better solution than Brickficiency, even when the latter computed all combinations. The reason is that Brickficiency only uses 2 decimal digits for the part price, whereas BrickLink uses at least 3. After multiplying that price with the part quantity BrickLink then rounds the lot subtotal to 2 decimal digits.
So if a part costs $ 0.016 and you order 1000, BrickLink will compute the lot subtotal to $16, whereas Brickficiency will compute it to $20. (And FWIW the rounding appears to goe the other way, too.)
Here is the example, where BrickLink finds a better result:
Here is one position from the Brickficiency result file:
And the same position in the BrickLink shopping cart:
Of course the error is small, in my case less than a percent of the amount, but could be a few percent in some cases. Still every penny counts, so it would be nice, if Brickficiency could use the same number of digits for the part price as BrickLink.