I have data as below:
241 97,5 143,5 17,5 21
203 90 113 8 23
I've loaded it to a hive table, and put data type as double but I've lost precision of data
For example 97,5 become 97,0
Perhaps it's a problem with the comma but I cant change my input file.
I've also tried to change the data type to string, it still the same but after I needed sum function it cast it to decimal I think so those values doesn't count at all.
Related
I'm trying to calculate a row value based on the previous row value in the same column within a report expression. I can't precalculate this from database since starting point of calculation is dependent from input parameters and values in a table should be recalculated dynamically within report itself.
In Excel analogical data and formula look like as it is shown below (starting point is always 100):
B C D E
Price PreviousPrice CalcValue Formula
1 NULL NULL 100
2 2.6 2.5 104 B2/C2*D1
3 2.55 2.6 102 B3/C3*D2
4 2.6 2.55 104 B4/C4*D3
5 2.625 2.6 105 B5/C5*D4
6 2.65 2.625 106 B6/C6*D5
7 2.675 2.65 107 B7/C7*D6
I tried to calculate expected values ("CalcValue" is the name of column where expression is set) like this:
=Fields!Price.Value/ PreviousPrice.Value * Previous(reportitems("CalcValue").Value))
but got an error "Aggregate functions can be used only on report items contained in page headers and footers"
Can you please advice whether expected result is achievable in my case and suggest a solution?
Thank you in advance!
Sadly I'm still facing with issue: calculated column does not consider previous calculated value. E.g., I added CalcVal field with 100 as default and tried to calculate using above approach, like: =previous(runningValue(Fields!CalcVal.Value, sum, "DataSet1") ) * Fields!Price.Value/Fields!PreviousPrice.Value.
But in this case it always multiples Fields!Price.Value/Fields!PreviousPrice.Value by 100..
For example CalcVal on Fly always show 200
=previous(runningValue(Fields!CalcVal.Value, sum, "DataSet1")) * 2
https://imgur.com/Wtg3Wsg
I tried with your sample data, here is how I achieved the results
Formula to use, You might have to take care of null values
=Fields!Price.Value/(Fields!PreviousPrice.Value*Previous(Fields!CalcValue.Value))
Edit: Update to answer after Op's comment
CalcValue is caluated with below formula i.e on the fly
=RunningValue(CountDistinct("Tablix6"),Count,"Tablix6"*100
and then Final value as below
=Fields!Price.Value/(Fields!PreviousPrice.Value*
Previous(RunningValue(CountDistinct("Tablix6"),Count,"Tablix6"))*100)
I need to create LMDBs dynamically that can be read by Caffe's data layer, and the constraint is that only C is available for doing so. No Python.
Another person examined the byte-level contents of a Caffe-ready LMDB file here: Caffe: Understanding expected lmdb datastructure for blobs
This is a good illustrative example but obviously not comprehensive. Drilling down led me to the Datum message type, defined by caffe.proto, and the ensuing caffe.pb.h file created by protoc from caffe.proto, but this is where I hit a dead end.
The Datum class in the .h file defines a method that appears to be a promising lead:
void SerializeWithCachedSizes(::google::protobuf::io::CodedOutputStream* output) const
I'm guessing this is where the byte-level magic happens for encoding messages before they're sent.
Question: can anyone point me to documentation (or anything) that describes how the encoding works, so I can replicate an abridged version of it? In the illustrative example, the LMDB file contains MNIST data and metadata, and 0x08 seems to signify that the next value is "Number of Channels". And 0x10 and 0x18 designate heights and widths, respectively. 0x28 appears to designate an integer label being next. And so on, and so forth.
I'd like to gain a comprehensive understanding of all possible bytes and their meanings.
Additional digging yielded answers on the following page: https://developers.google.com/protocol-buffers/docs/encoding
Caffe.proto defines Datum by:
optional int32 channels = 1
optional int32 height = 2
optional int32 width = 3
optional bytes data = 4
optional int32 label = 5
repeated float float_data = 6
optional bool encoded = 7
The LMDB record's header in the illustrative example cited above is "08 01 10 1C 18 1C 22 90 06", so with the Google documentation's decoder ring, these hexadecimal values begin to make sense:
08 = Field 1, Type = int32 (since tags are encoded by: (field_number << 3) | wire_type)
01 = Value of Field 1 (i.e., number of channels) is 01
10 = Field 2, Type = int32
1C = Value of Field 2 (i.e., height) is 28
18 = Field 3, Type = int32
1C = Value of Field 3 (i.e., width) is 28
22 = Field 4, Type = length-delimited in bytes
90 06 = Value of Field 4 (i.e., number of bytes) is 1580 using the VarInt encoding methodology
Given this, efficiently creating LMDB entries directly with C for custom, non-image data sets that are readable by Caffe's data layer becomes straightforward.
not sure this is the right place to ask but I have one set of "strings" (compiled from to int converted char) that I need to convert to a char array.
This is an example of the 5 integers:
13497
13621
13673
13547
13691
And this is the same set I need:
132
0
52
182
5
Is there an easy to way to convert them?
Edit: For added difficulty I can't find how the first set was made exactly.
In my view which I am exporting to excel, I display the value of this variable
VeryGoodPercentage = subQst.Question.ReponseList.Where(
r => r.ReponseValeur == 4 &&
Model.SelectedGroupContactList.Select(c => c.ContaId).Contains(r.ContaId.Value)
).ToList().Count() * 100
/
denominator;
And I display this way
<td class=xl76 align=right width=69 style='width:52pt'>#Math.Round(VeryGoodPercentage)%</td>
When I display the view without exporting to excel, everything works just fine. But when I open the exported Excel file, I found the value of that variable not rounded.
For examlpe :
In the view : 36%
In the excel file : 0.36
I use this line to generate the file:
Response.AddHeader("Content-Type", "application/vnd.ms-excel");
As stated:
36% and 0.36 should be the same - just excel did not fomat this as a percentage or did indeed interpreted 36 as a percentage - which will result in 0.36 as a number.
I don't see that this is a rounding problem, it is formatting or input or both.
Depending on what values #Math.Round(VeryGoodPercentage) produce - 0.xx or XX.XX - with % sign or without, excel will interpret this differently.
Some examples:
=0.36 will result in a number of 0.36
=36 will result in a number of 36
no suprises so far, but now:
=0.36% will result to 0.0036
=36% will result to 0.36
BUT those were Formulars, now if you would just use F2 on an empty 'default' formatted cell and write into it:
36% -> you would format this as percentage, which would display this as 36%, but if you would format it as 'default', then it would be the number 0.36!
0.36% -> would behave like 36%
hope this clears more than it confuses ;) good luck to you!
edit: and to make this even more fuzzy, in my country . is the symbol for thounsands, so you would have to use , instead.
edit: with VBA you could setup your column or cell to use a specific numberformat like this:
Table1.Columns("A").NumberFormat = "0.00%"
I finally found the solution here
Format HTML table cell so that Excel formats as text?
just add this css param to the tag :
mso-number-format:Percent;
I'm trying to do a little partitioning, dividing list entries into 6-month blocks. Using this LINQ to Entities query, I get results that imply that integer division is not taking place:
from e in enrollments
let AgeInHalfYears = e.AgeMonths / 6
select new { e.AgeMonths ,
AgeInHalfYears,
AgeFloor = ((int)AgeInHalfYears) * 6 }
My results are:
AgeMonths AgeInHalfYears AgeFloor
68 11 68
41 7 41
34 6 34
I would have expected 66, 36, and 30 in that last column.
I rewrote the LINQ pretty simply as
AgeFloor = e.AgeMonths - (e.AgeMonths % 6)
But I'm still curious about why the division operation is clearly floating point, even with that (int) cast in there... I wouldn't have expected that.
The Entity Framework is probably ignoring your cast when generating the SQL.
LINQ-based SQL generators are rarely (if ever) perfect.
In particular, .Net's type system is different enough from SQL's that they probably ignore all casts.
Try calling Math.Floor instead.