I have the current time in seconds like this:
The_Seconds : DAY_DURATION;
And I wish to convert it to an Integer. How can I do it?
Thank you.
What's the definition of DAY_DURATION?
If it's just in seconds it might be an integral type so Integer( The_Seconds ) would work; if it's a Float that syntax should also work, but you'll have to give some thought to whether to truncate, round, or ceiling it before conversion [look into the floating-point Attributes].
Day_Duration is a subtype of Duration, which is a fixed point type declared in package Standard.
Just type convert it.
Related
I am learning Julia and I would like to create an object in Julia that contains just a single large integer, for example, 1100000. What I could do is write n = 1.1e6 but then the type of this object is Float64 and if I want to use it as an argument for rand(), I get an error message because the object is not an integer. So instead what I do is as follows.
n = Int64(1.1e6)
rand(n)
But it seems that I am changing the type of the variable here (from Float64 to Int64) and this should be avoided in Julia as far as I understand. Of course I could use n = 1100000 but this is inefficient and difficult to read in my opinion.
Am I changing the type of the variable here? If yes, is this a good way to change the type of the variable or is there a better way to create an integer using scientific notation without having to change the type of the variable?
Any help is much appreciated!
I would write it as:
n = 1_100_000
for me it is more readable than
n = Int(1.1e6)
(or even 1.1e6) but of course it is subjective.
Changing type like in Int(1.1e6) is not a problem in Julia. It will work, as long as passed float represents an integer (otherwise you will get InexactError error).
i made a rsa-encryption demo to learn julia but ran into a problem.
this should be no issue of overflow and all values fit rsa criteria when i check with python code.
any pointers are welcome. julia is an awesome language and i would like to figure this out.
check these images to see my problem:
You need BigInt(message)^used_e, and similar. The problem you are seeing is integer overvflow before you convert to BigInt. Note that powermod(BigInt(message), used_e, used_N) will be much faster since it will keep all the intermediate numbers smaller.
Note that in Julia x % y is a synonym for the rem(x, y) function “from Euclidean division, returning a value of the same sign as x”, whereas for an RSA implementation, you need the mod function instead, where the result has the same sign as y. (But you really actually want powermod over BigInt here for performance.)
I'd like to convert binary to decimal in Julia. It looks like parseint() became deprecated.
Is the below method the best way to do this?
julia> parse(Int,"111",2)
7
Are you starting with a string? Then yes, that's the way. If you're just wanting to write a constant in binary, then it's much easier to just use the 0b111 syntax. By default, it constructs an unsigned integer (which is displayed in hexadecimal), but you can easily convert it to a signed integer with Int(0b111).
julia> 0b110111
0x37
julia> Int(0b110111)
55
It looks like the default for WinDbg is to display ints in decimal and unsigned ints in hexadecimal.
Is there a way to show all in decimal?
I tried using the n command mentioned here
It gives me syntax error though:
:086> n[10]
^ Syntax error in 'n[10]'
Any idea what am I doing wrong?
It seems that you are using square brackets when you shouldn't. On the MSDN page, those square brackets are there to show that the radix argument is optional.
When the argument is left off, the current radix is displayed to you.
0:000> n
base is 10
When you provide the argument (with no square brackets) the current radix is changed and echoed back to you.
0:000> n 16
base is 16
A commonly used trick once the base is set is to use the ? (Evaluate Expression) command to convert numbers to the new base (in this example, base 16).
0:000> ? 0n10
Evaluate expression: 10 = 0000000a
0:000> ? 0y11
Evaluate expression: 11 = 00000003
To convert from hex (base 16) back to decimal:
0:000> ? a
Evaluate expression: 10 = 0000000a
Remember that once the base is set, both input and output are affected meaning that when you want to enter a number that isn't is the current base, you will need to specify the base as was done above in the final example. Further reading on how numbers are handled in the MASM-like syntax is available here.
But back to your original question...
Yes, n 10 should be enough to force numbers to be displayed in decimal. If for some reason there is a problem, you can always use the ? command as shown above to perform the conversion.
Extended article describing how WinDbg evaluates expressions (including details on the impact of the n command) available here:
https://www.osronline.com/article.cfm?id=540
try using the command:-
.enable_long_status 0
So I'm just going to dive into this issue... I've got a heavily used web application that, for the first time in 2 years, failed doing an equality check on two doubles using the equality function a colleague said he'd also been using for years.
The goal of the function I'm about to paste in here is to compare two double values to 4 digits of precision and return the comparison results. For the sake of illustration, my values are:
Dim double1 As Double = 0.14625000000000002 ' The result of a calculation
Dim double2 As Double = 0.14625 ' A value that was looked up in a DB
If I pass them into this function:
Public Shared Function AreEqual(ByVal double1 As Double, ByVal double2 As Double) As Boolean
Return (CType(double1 * 10000, Long) = CType(double2 * 10000, Long))
End Function
the comparison fails. After the multiplication and cast to Long, the comparison ends up being:
Return 1463 = 1462
I'm kind of answering my own question here, but I can see that double1 is within the precision of a double (17 digits) and the cast is working correctly.
My first real question is: If I change the line above to the following, why does it work correctly (returns True)?
Return (CType(CType(double1, Decimal) * 10000, Long) = _
CType(CType(double2, Decimal) * 10000, Long))
Doesn't Decimal have even more precision, thus the cast to Long should still be 1463, and the comparison return False? I think I'm having a brain fart on this stuff...
Secondly, if one were to change this function to make the comparison I'm looking for more accurate or less error prone, would you recommend changing it to something much simpler? For example:
Return (Math.Abs(double1 - double2) < 0.0001)
Would I be crazy to try something like:
Return (double1.ToString("N5").Equals(double2.ToString("N5")))
(I would never do the above, I'm just curious about your reactions. It would be horribly inefficient in my application.)
Anyway, if someone could shed some light on the difference I'm seeing between casting Doubles and Decimals to Long, that would be great.
Thanks!
What Every Computer Scientist Should Know About Floating-Point Arithmetic
Relying on a cast in this situation is error prone, as you have discovered - depending upon the rules used when casting, you may not get the number you expect.
I would strongly advise you to write the comparison code without a cast. Your Math.Abs line is perfectly fine.
Regarding your first question:
My first real question is: If I change
the line above to the following, why
does it work correctly (returns True)?
The reason is that the cast from Double to Decimal is losing precision, resulting in a comparison of 0.1425 to 0.1425.
When you use CType, you're telling your program "I don't care how you round the numbers; just make sure the result is this other type". That's not exactly what you want to say to your program when comparing numbers.
Comparing floating-point numbers is a pain and I wouldn't ever trust a Round function in any language unless you know exactly how it behaves (e.g. sometimes it rounds .5 up and sometimes down, depending on the previous number...it's a mess).
In .NET, I might actually use Math.Truncate() after multiplying out my double value. So, Math.Truncate(.14625 * 10000) (which is Math.Truncate(1462.5)) is going to equal 1462 because it gets rid of all decimal values. Using Truncate() with the data from your example, both values would end up being equal because 1) they remain doubles and 2) you made sure the decimal was removed from each.
I actually don't think String comparison is very bad in this situation since floating point comparison is pretty nasty in itself. Granted, if you're comparing numbers, it's probably better to stick with numeric types, but using string comparison is another option.