ACCEPTED SOLUTION
Accepted Solutions
Ah, I see now. And now I am wondering why you posted a sheet with a value of d where the issue is NOT showing up!??
I set the duty cycle d to 35% and I get this:
The function returns 0 while its supposed to return 1.
Reason is that you experience simple rounding errors. These are common when dealing numerically in a computer program and cannot be avoided. An often seen example is shown below, showing that even just the order a calculation is done can make a difference:
When we let Mathcad show the max of 17 decimals we see whats going on.
The values of tc and tc(1+d) seem to be exact 1 s and 1.35 s,
but decimal numbers like these most of the times cannot be stored exactly in binary representation and when you use them for any calculations the round-off errors may show up in the results as can be seen here:
Even simple and obvious calculations can yield unexpected rounding errors:
Thats the reason why in programming its a rule not to ask if a value is exactly zero but rather if its approximately zero (if |value|<10^-12 or the like).
If that effect is a severe issue in your application, you might add a small number like this:
Another option can be to round every numbers involved down to a certain precision.
I found that all it needs it to round tc down to nanoseconds (use the "Round" function with an upper case "R" to do so)
This at least solves the problem for d=35% and the second cycle. No guarantee that it will also work for the fifth cycle or for other values of d. It may be necessary to round down ALL involved numbers. E.g. I found that when I still use d=35% but use picoseconds instead of nanoseconds he problem persists. So it might be a better idea to round down all numbers used in the function and no the number stored on worksheet level.
(it should not be necessary to define tc rounded down as shown before)
I guess picoseconds may be to small as some round-off errors might be larger. You have to find a value which is a good compromise between accuracy of results and elimination of round-off and conversion errors.
There sure are other ways to define a pulse (using the Heaviside function or using the if-function instead of the boolean expression) and to make it periodic you could replace the mod(a,b) function by a-b*trunc(a/b), but rounding errors can happen no matter what kind of calculation expression you are using.
I wonder what you think is wrong in the file you posted. Your function returns 1 for every positive multiple of 0.5 s and thats the way you defined your function. I am not sure what you mean by the "function turning off one time step too soon in the second cycle".
Here is your "check" as I see it when i open your file. Do you experience different results?
BTW, Mathcads definition of Hz is not wrong, its just not the one you are used to. Thats the reason Mathcad also provides a unit Hza.
Ah, I see now. And now I am wondering why you posted a sheet with a value of d where the issue is NOT showing up!??
I set the duty cycle d to 35% and I get this:
The function returns 0 while its supposed to return 1.
Reason is that you experience simple rounding errors. These are common when dealing numerically in a computer program and cannot be avoided. An often seen example is shown below, showing that even just the order a calculation is done can make a difference:
When we let Mathcad show the max of 17 decimals we see whats going on.
The values of tc and tc(1+d) seem to be exact 1 s and 1.35 s,
but decimal numbers like these most of the times cannot be stored exactly in binary representation and when you use them for any calculations the round-off errors may show up in the results as can be seen here:
Even simple and obvious calculations can yield unexpected rounding errors:
Thats the reason why in programming its a rule not to ask if a value is exactly zero but rather if its approximately zero (if |value|<10^-12 or the like).
If that effect is a severe issue in your application, you might add a small number like this:
Another option can be to round every numbers involved down to a certain precision.
I found that all it needs it to round tc down to nanoseconds (use the "Round" function with an upper case "R" to do so)
This at least solves the problem for d=35% and the second cycle. No guarantee that it will also work for the fifth cycle or for other values of d. It may be necessary to round down ALL involved numbers. E.g. I found that when I still use d=35% but use picoseconds instead of nanoseconds he problem persists. So it might be a better idea to round down all numbers used in the function and no the number stored on worksheet level.
(it should not be necessary to define tc rounded down as shown before)
I guess picoseconds may be to small as some round-off errors might be larger. You have to find a value which is a good compromise between accuracy of results and elimination of round-off and conversion errors.
There sure are other ways to define a pulse (using the Heaviside function or using the if-function instead of the boolean expression) and to make it periodic you could replace the mod(a,b) function by a-b*trunc(a/b), but rounding errors can happen no matter what kind of calculation expression you are using.
