Why are my decimals ignored when I have e (Exponent) inside it? When I type 53e6, it gives the exact same result as 53.e6 (53000000). I would expect the output of the latter to be 53.000000 or just 53... A note would be that 5.3e6 is different. I'm not sure why this happens.
I tested this in C, C++, Java, JavaScript, and Python—they all give the same result. Here's an example in JavaScript:
console.log("53e6:", 53e6);
console.log("53.e6:", 53.e6);
console.log("53e6 equals 53.e6?", 53e6 === 53.e6);
Can anyone explain this?
Related
I am missing a part to solve my problem.
If I do this operation :
TYPES: ty_p2 TYPE p DECIMALS 2.
DATA: lv_test TYPE ty_p2.
lv_test = '100.00' * '3.00'.
I got this result in a program (specific program) on debugger view :
this is the actual result I expect.
I got this result in a program (enhancement of a standard) on debugger view :
it's not the right result it's as if it were 100*3000 and it doesn't take into account the comma of the right hand operator of the multiplication.
How do you explain this ?
Is there an instruction which applies to the context of the ABAP session and which can modify the interpretation of the packed number during a multiplication? Or do you know where it comes from?
Thanks !
Fixed point arithmetic is not checked for the program.
When you are in change mode in SE38 (or SE80), use Menü Goto => Attributes
A popup comes up the checkbox for "Fixed point arithmetic" has to be checked (bottom-right corner of the popup window):
Using F1 Help on the field gives detailed explanation:
I am using swift5 and I am trying to sum by property like this:
let total = realm.objects(Purchase.self).sum(ofProperty: "amount")
but i get this error:
Type of expression is ambiguous without more context
what can I do?
Probably the easist solution is to let the compiler know what kind of result the sum will be.
Like this
let total: Double = realm.objects(Purchase.self).sum(ofProperty: "orderProperty")
print(total)
This tells the compiler than total will always be a Double
As a side note, Double's are (generally) not a good type to work with for financial situations. Look into Decimal (akin to NSDecimal and Decimal128)
#Persisted var decimal: Decimal128
in newer versions
am trying to create a settings file like:
[graph] weight=3.154
[ui] color=#00FFC1
but am getting something like
[graph] weight=#Variant(\0\0\0\x87#]/\x1b)
[ui] color=#00FFC1
my code is simple and looks like
QSettings settings("foo.ini", QSettings::IniFormat);
settings.beginGroup("graph");
settings.setValue("weight", 3.456f);
settings.endGroup();
settings.beginGroup("ui");
settings.setValue("color", "#00FFC1");
settings.endGroup();
settings.sync();
qt5.7.1 for linux 64bits
You are not really missing anything. All you see is how Qt encodes INI-Files. Since there is no standard describing how certain types should be represented in an INI-File, Qt defined their own. See https://doc.qt.io/qt-5/qsettings.html#Format-enum for more details. In short, any "special" type is represented by #<typename>(<data>), with most of them beeing further encoded as QVariant, for which the data you see is #Variant(<metaTypeId><data>). The metatype id for float is 8, or \0\0\0\x8 encoded as 32-bit hex string. All the stuff after those 4 characters is the actual binary data, as QDataStream::operator<< would produce it. However, to make INI-Files at least somewhat readable and compatible to those written by other applications, some types (like QString, int, double, bool, ...) use a different, more commonly known representation.
For this concrete case, they decided to not program such an encoding exception for the float type. The exact reason is unknown to me, but my personal guess would be that they wanted to make it possible to tell the difference between doubles and floats in the INI-Files, so someone does not accidentily interpret a float as double (and thus assume a given number has double precision, even though it has not).
A predicate on booleans seems a little silly to me (well, at least in the following scenario):
static Set<A> aSet = ...;
checkCondition(B b) {
return aSet.stream()
.map(b::aMethodReturningBoolean)
.filter((Boolean check) -> check)
.limit(1).count() > 0;
}
What I am doing is that given the object b, checking whether there is at least one member of aSet that satisfies a certain condition with respect to b.
Everything is working fine, but the line filter((Boolean check) -> check) is like a tiny little pin pricking me! Is there a way I can avoid it? I mean, if I have a line in my code that is literally the identity function, then there must be something wrong with my approach.
All you need is
return aSet.stream().anyMatch(b::aMethodReturningBoolean);
which is much more readable.
I am using the Kernel Density Estimator toolbox form http://www.ics.uci.edu/~ihler/code/kde.html . But I am getting the following error when I try to execute the demo files -
>> demo_kde_3
KDE Example #3 : Product sampling methods (single, anecdotal run)
Attempt to reference field of non-structure array.
Error in double (line 10)
if (npd.N > 0) d = 1; % return 1 if the density exists
Error in repmat (line 49)
nelems = prod(double(siz));
Error in kde (line 39)
if (size(ks,1) == 1) ks = repmat(ks,[size(points,1),1]); end;
Error in demo_kde_3 (line 8)
p = kde([.1,.45,.55,.8],.05); % create a mixture of 4 gaussians for
testing
Can anyone suggest what might be wrong? I am new to Matlab and having a hard time to figure out the problem.
Thank You,
Try changing your current directory away from the #kde folder; you may have to add the #kde folder to your path when you do this. For example run:
cd('c:\');
addpath('full\path\to\the\folder\#kde');
You may also need to add
addpath('full\path\to\the\folder\#kde\examples');
Then see if it works.
It looks like function repmat (a mathworks function) is picking up the #kde class's version of the double function, causing an error. Usually, only objects of the class #kde can invoke that functions which are in the #kde folder.
I rarely use the #folder form of class definitions, so I'm not completely sure of the semantics; I'm curious if this has any effect on the error.
In general, I would not recommend using the #folder class format for any development that you do. The mathworks overhauled their OO paradigm a few versions ago to a much more familiar (and useful) format. Use help classdef to see more. This #kde code seems to predate this upgrade.
MATLAB gives you the code line where the error occurs. As double and repmat belong to MATLAB, the bug probably is in kde.m line 39. Open that file in MATLAB debugger, set a breakpoint on that line (so the execution stops immediately before the execution of that specific line), and then when the code is stopped there, check the situation. Try the entire code line in console (copy-paste or type it, do not single-step, as causing an uncatched error while single-stepping ends the execution of code in debugger), it should give you an error (but doesn't stop execution). Then try pieces of the code of that code line, what works as it should and what not, eg. does the result of size(points, 1) make any sense.
However, debugging unfamiliar code is not an easy task, especially if you're a beginner in MATLAB. But if you learn and understand the essential datatypes of MATLAB (arrays, cell arrays and structs) and the different ways they can be addressed, and apply that knowledge to the situation on the line 39 of kde.m, hopefully you can fix the bug.
Repmat calls double and expects the built-in double to be called.
However I would guess that this is not part of that code:
if (npd.N > 0) d = 1; % return 1 if the density exists
So if all is correct this means that the buil-tin function double has been overloaded, and that this is the reason why the code crashes.
EDIT:
I see that #Pursuit has already addressed the issue but I will leave my answer in place as it describes the method of detection a bit more.