We Keep Coding

How to limit number of locations for each vehicle in Google OR-Tools Route Optimization

I have implemented Or-Tools for route optimization. Its working fine. Only one thing which i want to achieve that limit number of locations for each vehicle. For example, maximum two(2) locations defined for each vehicle.
I have tried to implement Capacity Constraint but it does not work. Also i tried to implement SetSpanUpperBoundForVehicle function, in this case solution object is null.
Here is my code
RoutingDimension timeDimension = routing.GetMutableDimension("Time");
timeDimension.SetSpanUpperBoundForVehicle(2, 0);
timeDimension.SetSpanUpperBoundForVehicle(2, 1);
timeDimension.SetSpanUpperBoundForVehicle(2, 2);
How can i limit this number of routes? Please help.

Simply create a counter dimension, at each location add 1, then for each vehicle limit the capacity to the number of maximum locations allowed.
e.g. reusing vrp.py sample and adding:
# Create counter
def counter_callback(from_index):
"""Returns 1 for any locations except depot."""
# Convert from routing variable Index to user NodeIndex.
from_node = manager.IndexToNode(from_index)
return 1 if (from_node != 0) else 0;
counter_callback_index = routing.RegisterUnaryTransitCallback(counter_callback)
routing.AddDimensionWithVehicleCapacity(
counter_callback_index,
0, # null slack
[4,5,4,6], # maximum locations per vehicle
True, # start cumul to zero
'Counter')
possible output:
%python vrp.py
Objective: 6780
Route for vehicle 0:
0 -> 7 -> 0
Distance of the route: 388m
Route for vehicle 1:
0 -> 14 -> 16 -> 15 -> 3 -> 4 -> 0
Distance of the route: 2716m
Route for vehicle 2:
0 -> 13 -> 12 -> 11 -> 1 -> 0
Distance of the route: 1804m
Route for vehicle 3:
0 -> 5 -> 8 -> 6 -> 2 -> 10 -> 9 -> 0
Distance of the route: 1872m
Total Distance of all routes: 6780m
As you can see, routes respect the 4, 5, 4, 6 locations limit.
Note: For C# syntax, it is barely the same see
https://github.com/google/or-tools/blob/stable/ortools/constraint_solver/samples/VrpCapacity.cs
and https://github.com/google/or-tools/blob/stable/ortools/constraint_solver/samples/VrpCapacity.csproj

C# Change affinity of an application

I am trying to change affinity of a program to use Core 1,2,3 and 4 of a CPU. And not the rest of them. I have searched a bit around.. I found this one: How Can I Set Processor Affinity in .NET?
But it didn't help me out..
I have a way to get the numbers of cores the CPU have. So it can adjust how many cores it will change it to. So it won't try to change it to more cores than the CPU got and so on..
Is there any easy way to do this?

I have successfully used the following to put my process on the the first CPU
Console.WriteLine("Press Enter to put the process onto Core 1");
Console.ReadLine();
Process Proc = Process.GetCurrentProcess();
long AffinityMask = (long)Proc.ProcessorAffinity;
AffinityMask &= 0x0001; // Put my process on the First Core
Proc.ProcessorAffinity = (IntPtr)AffinityMask;
Console.WriteLine("Process is now on Core 1");
Console.WriteLine("Press Enter to exit");
Console.ReadLine();
You can check in Task Manager the before and after affinity.
Update:
ProcessorAffinity represents each processor as a bit. Bit 0 represents processor one, bit 1 represents processor two, and so on.
The following table shows a subset of the possible ProcessorAffinity for a four-processor system.
Property value (in hexadecimal) Valid processors
0x0001 1
0x0002 2
0x0003 1 or 2
0x0004 3
0x0005 1 or 3
0x0007 1, 2, or 3
0x000F 1, 2, 3, or 4

Just as an extension to answer by #Rowan Smith, there is an additional way of writing binary numbers in C# 7.0 and higher - binary literals.
To specify hex literal one writes 0x at the beginning of number. For binary literals one should write 0b like this:
0b0000_0000_0000_0001 -> 1
0b0000_0000_0000_0010 -> 2
0b0000_0000_0000_1111 -> 1 & 2 & 3 4
You write them like:
int value = 0b0000_0000_0000_0001;
Some people might find it easier to write it like this instead of recalculating number between hex and binary representation, although the number itself is longer.

Reserved max value in the .NET assembly version

I wonder why the assembly version can not have the max UInt16 values. The MSDN states that:
All components of the version must be integers greater than or equal
to zero. Metadata restricts the major, minor, build, and revision
components for an assembly to a maximum value of UInt16.MaxValue - 1.
Does anyone know what the max value is reserved for?
UPDATE 1
It's not a duplicate question. I'm not asking about the max value of UInt16 itself, that is 65535. I'm asking why the max possible value for version is 65534. I haven't found any explanation about internal usage of the last value and why it is reserved in .NET.
UPDATE 2
People say that max value could be used for *. Yes, it is really possible to set the assembly version to something like 1.0.*. And I did it. And then checked the manifest of the compiled file:
And as you can see, compiler didn't set build and revision to 65535. Instead, it has generated some specific values. So, probably max value is not for *.

Why are build numbers limited to 65534?
FILEVERSION
Binary version number for the file. The version consists of two 32-bit integers, defined by four 16-bit integers. For example, "FILEVERSION 3,10,0,61" is translated into two doublewords: 0x0003000a and 0x0000003d, in that order. Therefore, if version is defined by the DWORD values dw1 and dw2, they need to appear in the FILEVERSION statement as follows: HIWORD(dw1), LOWORD(dw1), HIWORD(dw2), LOWORD(dw2).
Metadata restricts major, minor, build, and revision to a maximum of UInt16.MaxValue - 1. ref

c# 'invalid decimal constant' cannot be converted to a 'double' in Monodroid (Xamarin)

I'm trying to convert the decimal.MinValue to its double representation without any success, the compiler returns the 'invalid decimal constant' error with compilation failure.
------------- UPDATE :
The line thats doesn't compile is :
if (value < (double)decimal.MinValue || value > (double)decimal.MaxValue)
------------- END OF UPDATE
after looking for the definition of the MinValue constant (Update : Using the 'Go to definition' option on visual studio) it seems that the constant does not have the correct value, the constant was declared as below :
[DecimalConstant(0, 255, 4294967295, 4294967295, 4294967295)]
public const decimal MinValue = m;
so I have been curious to see the declaration of this same constraint on the .net framework (UPDATE : Using the 'Go to definition' option on visual studio) which I found completely different :
[DecimalConstant(0, 128, 4294967295, 4294967295, 4294967295)]
public const decimal MinValue = -79228162514264337593543950335m;
So the solution to my problem may be the replacement of the (double)decimal.MinValue cast by the value of that constant in the .net framework, but i need to be sure that this fix will have no impact on my app ? my be the mobile CPU-registers will not be able to hold a value with this size!
------------------- UPDATE :
My developement environnement is : Windows 8.1, Visual Studio 2013 Update 1 and mono-droid v4.10.01073.
------------------- END OF UPDATE

Reading all your edits and updates, there is absolutely no difference between using the constant decimal.MinValue and using the actual value itself. In fact, the compiler will replace all constants with their actual values when compiling your project, so the resulting compiled code is identical.

.NET: Large revision numbers in AssemblyVersionAttribute

We have the convention of versioning our builds as [major].[minor].[micro].[revision], e.g. 2.1.2.33546.
Our build-script automatically updates an AssemblyInfo.cs file containing
[assembly: AssemblyVersion("x.y.z.w")]
in order to embed the version-number in the assembly.
But our Subversion-repository just reached revision #65535, which broke our build.
It turns out that each number in the version-number has a maximum value of 65534 (probably due to a Windows-restriction).
Have you encountered this problem? Any good solutions/workarounds?
We like the scheme of embedding the revision-number and we obviously can't just reset our Subversion-server :-)

A bit more Background information:
Why are build numbers limited to 65535?
As this is unlikely to get changed, your options are:
Take the Revision Modulo 65535, which means you are back to 1
Use the Micro-Field in your version number to split the version number by dividing the revision by 1000. That means your version could be 1.0.65.535
Do not store the SVN Revision in the AssemblyVersion, but instead in the AssemblyInformationalVersion. That way your Application can still access it for display purposes, although you can't use Windows Explorer anymore to quickly check the SVN Revision
Do not store the SVN Revision in the AssemblyVersion, but instead in the AssemblyProduct or AssemblyDescription fields. Again, that way your Application can still access it, but also Explorer will now show it in the Property Sheet.

One option might be to just use the [AssemblyFileVersion]; this still raises a warning, but it'll build, at least:
[assembly: AssemblyFileVersion("1.0.0.80000")]

We decided to use the same convention, and due to the limitations of Windows version numbers we chose to drop the "micro" part of our version numbers in order to preserve the revision number. Our version numbers are now [major].[minor].[revision / 10000].[revision % 10000], so the assemblies built from revision 65535 have the version 2.01.6.5535.

According to MSDN, the components of the AssemblyVersionAttribute version number are limited to UInt16.MaxValue - 1 by the assembly meta data, i.e. you can't store larger numbers in an assembly file. The file version, as Marc Gravell suggests, might be enough for you, depending on who will read your version number.

This answer is for people, who use the Azure Build Pipeline, want to insert the BuildId value as last number of the assembly version and have a problem with a too large value of the BuildId. (> 65535)
My solution is to use the last 4 or 5 digits of the BuildId, which are injected into the file AssemblyInfo.cs.
I don't use the modulo operation, because than the version number would look totally different from the BuildId (after reaching the limit). Instead in my solution the "shorted" version looks similar to the BuildId.
Examples:
The AssemblyVersion is 1.0.0.0 and the BuildId is 333. --> The new AssemblyVersion becomes 1.0.0.333. (Small number, no problem.)
The AssemblyVersion is 1.0.0.0 and the BuildId is 55555. --> The new AssemblyVersion becomes 1.0.0.55555. (Still in range.)
The AssemblyVersion is 1.0.0.0 and the BuildId is 66666. --> The new AssemblyVersion becomes 1.0.0.6666. (Uses last 4 digits. More isn't possible.)
The AssemblyVersion is 1.0.0.0 and the BuildId is 111111. --> The new AssemblyVersion becomes 1.0.0.11111. (Uses last 5 digits.)
Easy usage by following steps
Step 1: Define the variable shortBuildId in your pipeline by this snippet.
variables:
- name: shortBuildId # note: The last 4 or 5 digits of the BuildId, because for the assembly version number the maximum value is 65535
value: '[not set]' # will be set by powershell script
Alternatively you could define it like this. It depends on the style how you did define your already existing variables.
variables:
shortBuildId: '[not set]'
Step 2: Insert these tasks above the existing tasks.
The first task creates the short BuildId and saves it to variable shortBuildId.
The second task updates the 4th version field in the file AssemblyInfo.cs. So the short buildId is injected into both, the AssemblyVersion and the AssemblyFileVersion.
Note: In this file you need an assembly version with 4 numbers (e.g. 1.0.0.0). If you have only 3 numbers (e.g. 1.0.0) it will not work.
- task: PowerShell#2
displayName: Define short build ID
# If allowed, use the last 5 digits. If they are larger than 65000, use the last 4 digits. Leading zeros are removed.
# This is needed, because the full build ID can't be used as number for the assembly version.
inputs:
targetType: 'inline'
script: |
$shortId = $env:BUILD_BUILDID
$shortId = $shortId % 100000
if ($shortId -gt 65000) { $shortId = $shortId % 10000 }
Write-Host "Build ID: $env:BUILD_BUILDID --> $shortId"
Write-Host "##vso[task.setvariable variable=shortBuildId]$shortId"
showWarnings: true
- task: RegexReplace#3
displayName: Insert shortBuildId into AssemblyInfo:
InputSearchPattern: 'myProjectDirectory\Properties\AssemblyInfo.cs'
FindRegex: '(\[assembly: (AssemblyVersion|AssemblyFileVersion)\("\d+\.\d+\.[0-9*]+)\.[0-9*]+("\)\])'
ReplaceRegex: '$1.$(shortBuildId)$3'
UseUTF8: true
UseRAW: true
Step 3: Adjust the path in the second task related to your project.
Edit the value of InputSearchPattern.
If you want to insert the shortBuildId into all projects of your solution, just write InputSearchPattern: '**\AssemblyInfo.cs'
Credit
Thanks to Dr. Edmund Weitz for his great tool The Regex Coach, which is free to use.

I'd like to propose by way of answer the following scheme for anyone using semver/gitflow:
AssemblyVersionAttribute
SemVer/Gitflow
Major Version
Major
Minor Version
Minor
Build Number
Patch
Revision
Gitflow ID
Where "Gitflow ID" is a digit followed by 0000 - 9999, per the following:
Gitflow ID
Branch
00000 - 09999
Release (alpha)
10000 - 19999
Release (beta)
20000 - 29999
Release (RC)
30000 - 65535
Development
The intuition behind 00000 - 29999 is that these numbers represent something of a logical negative pre-release number, 30000 represents logical zero, and 30001 - 65535 represent logical positive. More formally, this is a kind of 10's complement representation, with offset K = 30000.
So for example:
Topic branch feature/A starts at 0.0.0.30000
Simultaneously, topic branch feature/B also starts at 0.0.0.30000
feature/B merges to dev at 0.0.0.31000 while feature/A is at 0.0.0.30021
feature/A merges updates from dev at 0.0.0.31001
feature/A merges to dev at 0.0.0.32000
v1.0-alpha.1 release starts from dev at 1.0.0.00001
v1.0-rc.3 at 1.0.0.20002
Finally v1.0 released to Master at 1.0.0.30000
Hotfix v1.0.1 applied at 1.0.1.30000
Meanwhile v1.1 development continuing at 1.0.1.30002
The above suggests that the development range 30000-65535 could be further subdivided for topic branches, i.e. DDTTT, with DD ranging from 30 to 65 (max 65 - 30 + 1 = 36 dev PRs until release). Alternatively, the whole range could be used for development and topic branches without distinction; in this case, merging from dev to topic would have topic be dev + 1 and vice-versa. Either case allows there to be multiple identical version numbers at the topic branch level, but only a single version number for any dev commit. The DDTTT arrangement makes it clearer which version number represents a dev commit (e.g. 57000) at the expense of limiting the number of dev commits in a release. However, assuming a frequent enough release cadence, this should not be a problem. At any rate, production releases are clearly seen as having gitflow IDs of 30000.