I am trying to understand how does UWP's Windows.Storage.Streams.DataWriter.WriteDateTime method convert DateTimeOffset values to a byte array. I expected it to work similarly to TimeSpan, where the Ticks are converted to a byte array. Surprisingly, that is not the case.
For example, for DateTimeOffset.MinValue the byte sequence is:
248, 254, 49, 232, 221, 137, 0, 0
And for DateTimeOffset.MaxValue it is:
36, 200, 90, 94, 209, 192, 63, 255
I have tried comparing with output from DateTime.ToBytes() which gives much more reasonable results (e.g. MinValue yields all zeroes).
Can someone suggest or decode which logic is used?
A Windows.Foundation.DateTime is actually an int64 under the covers, representing the number of 100-nanosecond intervals prior to or after midnight on January 1, 1601. It's similar to a Windows FILETIME structure.
The .NET projection converts it to / from the DateTimeOffset structure for you, including any data transforms to the DateTimeOffset representation.
More info is on MSDN
Related
I am trying to getting data from mi scale V2. I am getting service data like this: “serviceData”: {“0000181b-0000-1000-8000-00805f9b34fb”: “BiTlBwcZFgsYAAAmAg==”}(5.15kg) and I decode the base64 string to array like this [66, 105, 84, 108, 66, 119, 99, 90, 70, 103, 115, 89, 65, 65, 65, 109, 65, 103, 61, 61] But I can not retrieve the correct result. How can I get the weight data?
The UUID 0000181b-0000-1000-8000-00805f9b34fb belongs to the pre-defined Body Composition Service (BCS). You can download the specification from here.
It should have the two characteristics Body Composition Feature and Body Composition Measurement.
The Features characteristic shows you the features supported by your scale, the measurement characteristic returns the actual measurement.
Take a look at this answer where I explain the process of decoding a sample weight measurement.
UUIDs with the format of 0000xxxx-0000-1000-8000-00805f9b34fb are an officially adopted Bluetooth SIG UUID and can be looked up online.
If you look at the following URL:
https://www.bluetooth.com/specifications/assigned-numbers/
there is a document with the title "16-bit UUIDs". I can see from that document that 0x181b is Body Composition GATT Service.
According to the "Body Composition Service 1.0" document at:
https://www.bluetooth.com/specifications/specs/
there should be a Body Composition Feature (0x2A9B) and a Body Composition Measurement (0x2A9C) characteristic available for that service.
It will be the Body Composition Measurement characteristic that will contain the weight value.
A generic Bluetooth Low Energy scanning and exploration tool like nRF Connect can be useful when exploring and understanding the data on a device.
Problem statement: I want to scan an image at maximum scanner resolution (6400 dpi on a Epson V850). This is partly possible from the Epson scanner "professional mode" in the software, provided that the scan area is limited to 21000 x 30000 pixels.
I'm ok with this limitation, I could simply scan small squares of the full area (at max resolution), then "stitch" them together afterwards.
I want to automate this, so I'm attempting to use pyinsane / SANE.
The issue is: the maximum resolution I can set is 1200, as you can see from the properties reported by pyinsane
dps_optical_xres=6400 ([])
dps_optical_yres=6400 ([])
resolution=300 ([50, 75, 100, 125, 150, 175, 200, 225, 250, 275, 300, 325, 350, 375, 400, 425, 450, 475, 500, 525, 550, 575, 600, 625, 650, 675, 700, 725, 750, 775, 800, 825, 850, 875, 900, 925, 950, 975, 1000, 1025, 1050, 1075, 1100, 1125, 1150, 1175, 1200])
xres=300 ([50, 1200, 1])
yres=300 ([50, 1200, 1])
optical_xres=6400 ([])
optical_yres=6400 ([])
So the question is: how do I override this setting so I am able to scan small areas at 6400dpi?
Again, using the EPSON Scan software I can scan at 6400dpi, provided the scanned area is small.
I know the limit exists for memory reasons, but it doesn't feel right that I can't adjust scan area and resolution, just like the Epson software allows to do.
The problems with using the Epson software is A) I can't automate the process, and B) I can't select an arbitrary scan area in terms of top-left to bottom-right coordinates.
I'm surprised how there is no definite answer on this yet. Let's try to have one once and for all, for posterity!
First of all, beware Pyinsane2 is not maintained anymore. Its replacement is Libinsane. (I'm the author of both).
The maximum of 1200dpi comes of the constraint on xres and yres: xres=300 ([50, 1200, 1]) and yres=300 ([50, 1200, 1]) (resolution is just an alias to those 2 options created by Pyinsane2).
Based on what you say, my guess is that you can get this constraint to go to higher values by setting first the scan area to a smaller one (see tl-x, tl-y, br-x, br-y). However after that, I don't think Pyinsane2 will reload the constraint on resolution correctly and so the max will remain 1200dpi (whereas Libinsane should reload it correctly).
By the way, just to be pedantic, if you have options like dps_optical_xres or optical_xres, you are not using Pyinsane2 on top of Sane (Linux), but Pyinsane2 on top of WIA2 (Windows).
For Linux there is ImageScan v3 with command line option.
I didn't try ImageScan v3 but scanimage (sane) on Ubuntu. 3200 ppi worked without problems.
I am just curious, is there any specific reason that numpy.rint does seem to support complex numbers e.g.
np.rint(3.1+2.3j)
(3+2j)
while numpy.floor numpy.ceil do not e.g.
np.floor(3.1+2.3j)
Traceback (most recent call last):
File "", line 1, in
TypeError: ufunc 'floor' not supported for the input types, and the inputs could not be safely coerced >to any supported types according to the casting rule ''safe''*
I use them in fixed point hardware simulation and it's a bit annoying to have separate real and image parts handled for np.floor while np.rint handles complex numbers just fine...
From the docs:
The floor of the scalar x is the largest integer i, such that i <= x. It is often denoted as \lfloor x \rfloor.
By your reasoning floor(1+2.3j) should be 1+2j, right? Let's test it:
It is true by numpy's comparison rules:
In [259]: np.array([1+2j])<=np.array([1+2.3j])
Out[259]: array([ True])
but not Python complex:
In [254]: 1+2j<=1+2.3j
Traceback (most recent call last):
File "<ipython-input-254-982f3ee0b6f8>", line 1, in <module>
1+2j<=1+2.3j
TypeError: '<=' not supported between instances of 'complex' and 'complex'
Python's implementation:
In [255]: import math
In [256]: math.floor(1+2.3j)
Traceback (most recent call last):
File "<ipython-input-256-be3a7370c225>", line 1, in <module>
math.floor(1+2.3j)
TypeError: can't convert complex to float
sympy is more explicit about generalization to complex:
Floor is a univariate function which returns the largest integer
value not greater than its argument. This implementation
generalizes floor to complex numbers by taking the floor of the
real and imaginary parts separately.
Octave/MATLAB is also explicit about its generalization.
I don't know if that generalization is mathematically robust or not. The Wiki article only has one mention of the complex. This math thread points out the ambiguity of this extension (due to the question of ordering of complex numbers).
https://math.stackexchange.com/questions/2095674/floor-function-in-complex-plane
I am learning seaborn from
http://seaborn.pydata.org/tutorial/aesthetics.html
In the import section,please explain this line
np.random.seed(sum(map(ord, "aesthetics")))
What this line does and please explain each element in this line.
In plotting offset sine wave how to define this
plt.plot(x, np.sin(x + i * .5) * (7 - i) * flip)
The importatnt thing first: This line np.random.seed(sum(map(ord, "aesthetics"))) is completely irrelevant for seaborn to work. So in principle you don't have to wory about it at all.
ord gives the byte represenation of a character
map applies a function to every item of an interable
sum sums up the elements of an iterable.
So map(ord, "aesthetics") will give a list of numbers, [97, 101, 115, 116, 104, 101, 116, 105, 99, 115] which when summed up, give 1069.
This number is then fed to np.random.seed. It is a seed for numpy's random number generator. By specifying the seed, you make sure that any random numbers drawn afterwards are based on this seed.
The point of this is to make random numbers reproducible. Having specified the seed allows me to know that when generating a random number like np.random.randint(10) the result will be 4 (for seed 1069).
This is extremely useful to make examples reproducible, and it's the reason they use it in the seaborn tutorial to make sure that the plots generated from random numbers are actually the same everywhere.
One could of course argue that using this command is more confusing than it would confuse people to see different plots when reproducing the tutorial, but that's a different question I guess.
I'm developing an application that should use very few resources and be very fast. And in my app I use an unsigned char* rawData which contains bytes got from image. So in this rawData array I have to keep some bytes and others set to zero. But I'm not permitted to use any loop(otherwise I can just run through each byte and set them zero).
So here are questions.
Q1) Is there any method in Objective C like ZeroMemory in C
Q2) Is there any other ways to set nessecary bytes to zero without using any loop.
Thanks In Advance...
P.S. Can provide some code if nessecary...
If you don't know the size of the buffer, you can't do it without a loop. Even if you don't write the loop yourself, calling something like strlen will result in a loop. I'm counting recursion as a loop here too.
How do you know which bytes to keep and which to set to zero? If these bytes are in known positions, you can use vector operations to zero out some of the bytes and not others. The following example zeros out only the even bytes over the first 64 bytes of rawData:
__m128i zeros = _mm_setzero_si128();
uint8_t mask[] = {8, 0, 8, 0, 8, 0, 8, 0, 8, 0, 8, 0, 8, 0, 8, 0};
__m128i sse_mask = _mm_load_si128(mask);
_mm_maskmoveu_si128(zeros, sse_mask, &rawData[0]);
_mm_maskmoveu_si128(zeros, sse_mask, &rawData[16]);
_mm_maskmoveu_si128(zeros, sse_mask, &rawData[32]);
_mm_maskmoveu_si128(zeros, sse_mask, &rawData[48]);
If the high bit of each byte in mask is 1, the corresponding value in zeros will be copied to rawData. You can use a sequence of these masked copies to quickly replace some bytes and not others. The resulting machine code uses SSE operations, so this is actually quite fast. It's not required, but SSE operations will run much faster if rawData is 16-byte aligned.
Sorry if you're targeting ARM. I believe the NEON intrinsics are similar, but not identical.