I am trying to implement a constraint as follows:
routing.solver().Add(capacity_dimension.CumulVar(idx) * routing.ActiveVar(idx) >= capacity_dimension.CumulVar(routing.End(v)) * 0.5 )
It gives error:
TypeError: unsupported operand type(s) for *: 'IntVar' and 'float'
How can I resolve this?
I tried capacity_dimension.CumulVar(routing.End(v)).Value() * 0.5 on RHS but this kills the kernel.
Fixed on https://groups.google.com/g/or-tools-discuss/c/LS2vixRsI_Y/m/7NnpJIRyAgAJ
The solver is integral, instead of multiply one side by 0.5, multiply the other by 2.
Related
When I do the following:
let gapDuration = Float(self.MONTHS) * Float(self.duration) * self.gapMonthly;
I get the error:
Binary operator '*' cannot be applied to operands of type 'Float' and 'Float!'
But when I do:
let gapDuration = 12 * Float(self.duration) * self.gapMonthly;
Everything is working fine.
I have no Idea what this error is telling me.
self.gapMonthly is of type Float! and self.duration and self.MONTHS are of type Int!
I would consider this a bug (at the very least, the error is misleading), and appears to be present when attempting to use a binary operator on 3 or more expressions that evaluate to a given type, where one or more of those expressions is an implicitly unwrapped optional of that type.
This simply stretches the type-checker too far, as it has to consider all possibilities of treating the IUO as a strong optional (as due to SE-0054 the compiler will treat an IUO as a strong optional if it can be type-checked as one), along with attempting to find the correct overloads for the operators.
At first glance, it appears to be similar to the issue shown in How can I concatenate multiple optional strings in swift 3.0? – however that bug was fixed in Swift 3.1, but this bug is still present.
A minimal example that reproduces the same issue would be:
let a: Float! = 0
// error: Binary operator '*' cannot be applied to operands of type 'Float' and 'Float!'
let b = a * a * a
and is present for other binary operators other than *:
// error: Binary operator '+' cannot be applied to operands of type 'Float' and 'Float!'
let b = a + a + a
It is also still reproducible when mixing in Float expressions (as long as at least one Float! expression remains), as well as when explicitly annotating b as a Float:
let b: Float = a * a * a // doesn't compile
let a: Float! = 0
let b: Int = 0
let c: Int = 0
let d: Float = a * Float(b) * Float(c) // doesn't compile
A simple fix for this would be to explicitly force unwrap the implicitly unwrapped optional(s) in the expression:
let d = a! * Float(b) * Float(c) // compiles
This relieves the pressure on the type-checker, as now all the expressions evaluate to Float, so overload resolution is much simpler.
Although of course, it goes without saying that this will crash if a is nil. In general, you should try and avoid using implicitly unwrapped optionals, and instead prefer to use strong optionals – and, as #vadian says, always use non-optionals in cases where the value being nil doesn't make sense.
If you need to use an optional and aren't 100% sure that it contains a value, you should safely unwrap it before doing the arithmetic. One way of doing this would be to use Optional's map(_:) method in order to propagate the optionality:
let a: Float! = 0
let b: Int = 0
let c: Int = 0
// the (a as Float?) cast is necessary if 'a' is an IUO,
// but not necessary for a strong optional.
let d = (a as Float?).map { $0 * Float(b) * Float(c) }
If a is non-nil, d will be initialized to the result of the unwrapped value of a multiplied with Float(b) and Float(c). If however a is nil, d will be initialised to nil.
cifar8 = Input(name='cifar8',shape=(8,8,3),dtype='float32')
inner = Flatten()(cifar8)
en = Dense(1,activation='relu')(inner)
patch = Input(shape=(8,8,9),dtype='float32')
m = merge([en, patch], mode= scaleMult, output_shape = (None,8,8,9))
inner = Convolution2D(32, 3, 3, border_mode='same',activation='relu')(m2)
The function scaleMult means that the one element tensor 'en' multiply the 8×8×9 tensor 'patch'.
Of course, I should construct multiplication between 32*1 tensor 'en' and 32×8×8×9 tensor 'patch' when training in 32 size batch.
But there always shows the error 'fan_in = shape[1] * receptive_field_size TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'' at the Convolution2D step.
I want to something like:
select tan(angle) % (2*Pi())
Hence I get the folowing error: ERROR: operator does not exist: numeric % double precision any suggestions?
The modulo operator in postgres takes NUMERIC as arguments. Thus, you have to cast the operands:
SELECT TAN(angle)::NUMERIC % (2 * PI())::NUMERIC;
I am unable to calculate another columns by diving or multiplying
through below code-
csv_data["male Turnout"]=csv_data["Male Voters"]/csv_data["Male Electors"]
male turnout- New column name male voters- existing column male
electors- existing column
i am unable to understand how to convert str to int as it shows -
unsupported operand type(s) for /: 'str' and 'str' when ever i execute
code--
i also tried
mydata=float(csv_data())
to convert csv_data- my dataset name
This code fails:
let element: Float = self.getElement(row: 1, column: j)
let multiplier = powf(-1, j+2)*element
with this error:
Playground execution failed: :140:51: error: cannot invoke '*' with an argument list of type '(Float, Float)'
let multiplier = powf(-1, j+2)*element
Bear in mind that this occurs in this block:
for j in 0...self.columnCount {
where columnCount is a Float. Also, the first line does execute and so the getElement method indeed returns a Float.
I am completely puzzled by this as I see no reason why it shouldn't work.
There is no implicit numeric conversion in swift, so you have to do explicit conversion when dealing with different types and/or when the expected type is different than the result of the expression.
In your case, j is an Int whereas powf expects a Float, so it must be converted as follows:
let multiplier = powf(-1, Float(j)+2)*element
Note that the 2 literal, although usually considered an integer, is automatically inferred a Float type by the compiler, so in that case an explicit conversion is not required.
I ended up solving this by using Float(j) instead of j when calling powf(). Evidently, j cannot be implicitly converted to a Float.