After running the following code, I got this error. But I don't know what the error means and how to solve it?
code with the error :
you missed multiplying (*) after (h), which python is considering as function which is obviously not found. Change the code in line number to below code
volume = 1/3 * 22/7 * h * (R1*R1 +R2*R2 +R1*R2)
Related
To anyone who has done Google's Foobar challenge before, have you ever encountered an error like this?
Verifying solution...
{
"bytes" : "CAAaIgogQ291bGQgbm90IGZpbmQgJ2Fuc3dlcicgZnVuY3Rpb24"
}
I've tested my solution in Visual Studio, and it works fine, and it gives accurate output. I only have 36 hours remaining to submit my solution, and this is the final challenge, so I would really like to get credit for completing it. Here's the code I'm trying to verify:
from fractions import *
from math import factorial as fac
def cycle_index(n):
return [(coeff(term), term) for term in foo(n, n)]
def foo(n, lim):
soln_set = []
if n > 0:
for x in range(lim, 0, -1):
if x == 1:
soln_set.append([(1, n)])
else:
for y in range(int(n / x), 0, -1):
recurse = foo(n - x * y, x - 1)
if len(recurse) == 0:
soln_set.append([(x, y)])
for soln in recurse:
soln_set.append([(x, y)] + soln)
return soln_set
def coeff(term):
val = 1
for x, y in term:
val *= fac(y) * x ** y
return Fraction(1, val)
def cross(cycle_a, cycle_b):
term = []
for len_a, freq_a in cycle_a:
for len_b, freq_b in cycle_b:
lcm = len_a * len_b / gcd(len_a, len_b)
term.append((lcm, int(len_a * freq_a * len_b * freq_b / lcm)))
return term
def answer(w, h, s):
total = 0
cycidx_cols = cycle_index(w)
cycidx_rows = cycle_index(h)
for col_coeff, col_cycle in cycidx_cols:
for row_coeff, row_cycle in cycidx_rows:
coeff = col_coeff * row_coeff
cycle = cross(col_cycle, row_cycle)
value = 1
for _, power in cycle:
value *= s ** power
total += coeff * value
return total
I found someone else's solution last week and verified it through Foobar, but I wanted to write my own to get a deeper understanding. I've compared results side-by-side, and they are exact, so I know my code gives accurate results.
Out of curiosity, I just retried verifying the other person's solution again, and now I am getting the same error with a slightly different output even though it worked just fine when I tried last week:
Verifying solution...
{
"bytes" : "CAEQARABEAEQARABEAEQARABEAEQAQ"
}
I'm not sure where else to go. I was so excited that I had come up with my own solution to the challenge, but now I'm panicking that it won't matter. Any suggestions?
UPDATE - June 29, 2018, 6:00pm CST
The deadline passed for me last night, and I was unable to submit my code in time. I made sure to use the recruitme command before time ran out just in case I got booted out. However, I am still able to view my current status, and it let me request another Level 5 challenge. So, I will be checking periodically to see if the test cases start showing up again, and I will be sure to update this when they do. I would highly recommend that anyone on lower levels wait until I confirm that this issue is fixed before attempting to request another challenge.
UPDATE - June 30, 2018, 5:00am CST
According to the pattern found by #RobertAnsel, I have completed the challenge. I confirmed this pattern by hardcoding the answer function to output solutions to the test cases given in the instructions. The resulting errors matched exactly with the predicted output. I also found an interesting thread on Google's Support Forum (linked here) where something similar happened to a bunch of Foobar challengers. It seems like their error was fixed by Google after about three days, but unfortunately, it also looks like a lot of people who timed out were not given another chance. Nevertheless, this will probably resolve itself within the next day or two. I will continue trying to verify and submit my solution until I am successful.
UPDATE - July 4, 2018, 12:00am CST
This issue seems to have been more or less resolved. Refer to the chosen answer for more details. Thanks a ton to #RobertAnsel for all the help! Some additional info: I was able to verify my current challenge, but upon submission, I was told that my time for the problem had expired. After logging in again, I was able to request a new challenge. I noticed I was also able to use the recruitme command again. I am not sure if this means they did not receive the first request or if you are allowed to use that command multiple times. Regardless, I am relieved that I am able to continue forward with Foobar. Best of luck to the rest of you!
This may not be the answer you're looking for, but that first "bytes" string is a base64 encoding of the following error message:
"Could not find 'answer' function".
I've done the Foobar challenge myself, and that should only happen if you are trying to verify a file that is missing a defined "answer" function, which obviously you are not. Are you certain that the spec they provide has 3 arguments vs an array with 3 items?
The second message (CAEQARABEAEQARABEAEQARABEAEQAQ), while valid base64, doesn't map to ASCII or UTF-8. After some closer analysis of some of the other strings others have posted, I've concluded that this is the base64 encoded version of the test output. It isn't very human readable, but I believe it is 11 2-byte chunks, the first of which is unhelpful, but the following 10 are the test result for each of the corresponding test cases. In the case of this message it converts to binary as:
0000100000000001 <- unknown pre-pended info
0001000000000001 <- passing test 1
0001000000000001 <- passing test 2
0001000000000001 <- passing test 3
0001000000000001 <- passing test 4
0001000000000001 <- passing test 5
0001000000000001 <- passing test 6
0001000000000001 <- passing test 7
0001000000000001 <- passing test 8
0001000000000001 <- passing test 9
0001000000000001 <- passing test 10
The '1's at the end of each of these lines indicates that all 10 tests are passing.
A failing test case is represented by the following string:
0001000000000000 <- failing test case
This should help you (and others) continue testing to achieve fully passing tests (you can complete your own analysis with tools like this one: https://cryptii.com/base64-to-binary), but unfortunately this will not help you move forward with your final submission until Google remediates the issue on their end.
UPDATE: July 2, 8PM PDT
After reaching out to a couple of Google recruiters about the issue they were able to confirm that the issue was identified and is believed to be resolved today.
If you re-save your code after making a change to it (whitespace should be fine), you should be able to test and submit correctly. Alternatively, you may now be able to request a new challenge anyway.
There will be nothing for you to solve this issue, it is a issue on Google's site, as the Google Foobar API is responding with this message as I've found out.
Notherless your best bet will be to use the feedback command and give Google Foobar a feedback and mark it as a bug. This will be more likely to reach their attention and helping them to fix this issue!
I am doing some maths on the GPU and reading the result.
And I am getting the wrong value From log. I have verified this for values 0 - 10, 20, 30, 40.
If I hard code the value (as you can see bellow under verify) I get the right result spat out. However if I use log with the hard coded value that should return the same result, I get the wrong result spat out.
This is the kind of thing I have been doing in my function.
vec4 IScale(vec4 value)
{
switch(uScaleType_i)
{
case Log:
//value = log(value);
value = vec4(1,1,1,1);
value.r = log(5);
//verifiy
//value.r = 0.698970004
break;
case Sqrt:
value = sqrt(value);
break;
case None:
break;
}
return value;
}
I am wondering is there any sense here. I have added the results of what I am getting back into excel and done a graph. At first Its almost like its double the correct value but its not quite that clean, it gets further and further away.
Is there any other explanation for this other than a driver issue? I cant think of anything else to check!
And if so how can i possibly work around it, other than refactoring my code to do it on the CPU? And why can't I find evidence online to back this up? I am completely utterly baffled!
I am running on a laptop with:
(Intel(R) HD Graphics 4000 with 132 ext.)
p.s. Sqrt is fine and I get the values I would expect.
p.p.s I checked, I have not accidentally created a function called "log"
I believe you are tripping over the base used for the log. In Excel the base is 10 however in glsl it is e.
To get the right result you should divide the result with the log of the base you want.
value = log(value)/log(10);
Or in excel you can use LN(RC[-1])
This is as per the specification. log() will return the natural logarithm, i.e. the logarithm to the base e. Not the base 10 logarithm.
I am working with the computer Vision toolbox in MATLAB 2014b
there is a function for Semi-global Matching (SGM )
I am trying to generate a disparity map of a stereo images. However, the disparity range needs to be quite large for some experiments.
Here is the function call:
Dmap = disparity(I1 I2, 'BlockSize', 15, 'DisparityRange', [-2466, 2466]);
The problem is the DisparityRange is limited to be in the range of [-2464, 2464]. Thus, I am getting an error msg like this one bellow.
Error using disparity
The value of 'DisparityRange' is invalid. Expected DisparityRange to be an array with all of the values >
-2466.
Error in vision.internal.disparityParser (line 38)
parser.parse(varargin{:});
Error in disparity>parseOptionalInputs (line 264)
r = vision.internal.disparityParser(imageSize, getDefaultParameters(),...
Error in disparity>parseInputs (line 244)
r = parseOptionalInputs(imageSize, varargin{:});
Error in disparity (line 137)
r = parseInputs(I1, I2, varargin{:});
My questions:
1. I could not find the function (vision.internal.disparityParser). Where is should be located.
2. I would like to modify the code to work for rainges beyond the specified limit. Is that possible?
3. For anyone who worked with the C++ version of the SGM function (OpenCV), does the same problem exist (i.e., the disparity range limits).
Thank you!
:)
I could only answer the first question. The function vision.internal.disparityParser is located at $MATLAB/toolbox/vision/vision/+vision/+internal/disparityParser.m .
This is hopefully a simple linker issue but I've spent hours searching and haven't moved forward in that time. I'm trying to use
#include <cmath>
double aA = 2;
double result = pow((double)2.0,(double)aA);
I get no error messages and it compiles without issue. But an unrelated grid I'm drawing with openGL doesn't display. If i substitute the aA for 2 then it displays the grid. Like
#include <cmath>
double aA = 2;
double result = pow((double)2.0,(double)2);
This outputs 4 as expected. The previous example outputs nothing. It's as if the program hangs but there are no errors.
This computation isn't used anywhere and in fact just sits in main (or anywhere else) and the variables are unique and are unused.
I'm using code::blocks and minGW GNU GCC compiler in Windows 7. -g -Wall - WExtra
Rendering with glew + freeglut and everything else works until i use a variable with pow.
I've tried every combination of casting I can think of and I've tried powf with the exact same result. I'm using sqrt and other functions so believe that the inclusion is working. I've also tried math.h but get the same problem.
I have never wished to see an error message from a compiler more so than I do right now.
So 1. Why am I not getting an error when it looks like its stopping the whole program in its tracks?
And 2. What have I missed to get pow() working with variables?
Update : After creating a new project and trying it out I have no issues so there must be something in my setup that's interfering. I'll keep experimenting. Thanks for the quick responses things sure move fast around here!
Update 2:
Very strange.
float aAs = 1.0;
float amplitudeA = (float)pow((float)2.,(float)aAs);
char str[50];
int test = (int) (amplitudeA);
sprintf (str, "out - %d", test);
MessageBox(NULL,str,NULL,NULL);
This outputs 2 in the message box. Then my grid draws and the program behaves. If i comment out only the message box like so:
float aAs = 1.0;
float amplitudeA = (float)pow((float)2.,(float)aAs);
char str[50];
int test = (int) (amplitudeA);
sprintf (str, "out - %d", test);
//MessageBox(NULL,str,NULL,NULL);
No drawing of my grid. What could be causing this?
char str[50];
int test = (int) (1);
sprintf (str, "out - %d", test);
MessageBox(NULL,str,NULL,NULL);
float aAs = 1.0;
float amplitudeA = (float)pow((float)2.,(float)aAs);
Swapping the message box over recreates the issue. No grid drawn. It's as if focus needs to be taken away from the program when I'm using a variable in pow. I'm completely baffled.
Another Update : I temporarily got around it by writing my own simple powerOf function. But now I'm having the same issue with the cos() function.
Can anyone tell me if there is something wrong with that image? This issue has to stem from incorrect linking. Is that what you would expect from hovering over coz in code::blocks with gcc?
This a error that occurs only when running through the program with a bad cos call. Interesting that I've been using cos for camera calculations since I started this app with no issue.
Error #667: UNADDRESSABLE ACCESS: reading 0x00000003-0x00000007 4 byte(s)
# 0 ntdll.dll!RtlImageNtHeader +0x124c (0x77ca43d0 <ntdll.dll+0x343d0>)
# 1 ntdll.dll!RtlImageNtHeader +0x422 (0x77ca35a7 <ntdll.dll+0x335a7>)
# 2 ntdll.dll!RtlImageNtHeader +0x30d (0x77ca3492 <ntdll.dll+0x33492>)
# 3 KERNEL32.dll!HeapFree +0x13 (0x775e14dd <KERNEL32.dll+0x114dd>)
# 4 atioglxx.dll!atiPPHSN +0x11afaa (0x66538f3b <atioglxx.dll+0xeb8f3b>)
# 5 atioglxx.dll!DrvSwapBuffers +0x33fb (0x6569b9cc <atioglxx.dll+0x1b9cc>)
# 6 atioglxx.dll!DrvSwapBuffers +0x3cad (0x6569c27e <atioglxx.dll+0x1c27e>)
# 7 atioglxx.dll!DrvSwapBuffers +0x7c57 (0x656a0228 <atioglxx.dll+0x20228>)
# 8 atioglxx.dll!DrvSwapBuffers +0x12c (0x656986fd <atioglxx.dll+0x186fd>)
# 9 atioglxx.dll!DrvValidateVersion +0x28 (0x65697c19 <atioglxx.dll+0x17c19>)
#10 OPENGL32.dll!wglSwapMultipleBuffers +0xc5d (0x66c8af0b <OPENGL32.dll+0x3af0b>)
#11 OPENGL32.dll!wglSwapMultipleBuffers +0xe45 (0x66c8b0f3 <OPENGL32.dll+0x3b0f3>)
Note: #0:00:05.233 in thread 3136
Note: instruction: mov 0x04(%ecx) -> %ecx
Solved. There was an uninitialized variable that was sitting at the bottom of the vertex buffer object I was using to draw the grid. For whatever reason feeding a variable to one of the math functions caused unexpected results in this buffer object.
Thanks to Angew an Kos for pointing me towards memory.
With only one atom type, I used:
pair_style eam/fs
pair_coeff * * /potentials/Zr_#2.eam.fs Zr
But I keep getting the error: Incorrect args for pair coefficients. I am also sure that the path to the potential file is correct. How can I fix this?
You're potential file is incorrectly named. LAMMPS will interpret the '#' in:
pair_coeff * * /potentials/Zr_#2.eam.fs Zr
as the start of a comment.
Rename your potential file and it should work.