I have to convert a given date to quarter.
This usually means (using floating point), I could use this algorithm in Nifi's expression language:
${start_dt
:toDate("yyyy-MM-dd'T'HH:mm:ssZ")
:format('MM','GMT')
:toNumber()
:divide(3)
:plus(0.9)
:toDecimal()}
The steps would be like this:
2019-11-10T12:00:00+0000 -> 11 -> 11 -> 3.66666 -> 4.56666 -> 4
2019-12-10T12:00:00+0000 -> 12 -> 12 -> 4 -> 4.9 -> 4
But instead I get 3.9 instead, only for Month 12 its working, so the toNumber() doesn't work. As perdocumentation, I have to convert to Number before a division, so that I get floating points, but apparently that doesn't work.
I don't want to use a script just for this little calcualtion.
Nifi version is 1.9.2
Using divide(3.0) instead of divide(3) solved the problem.
Documentation says, if one of the parameters is number, that one is used. Since I'm not a native speaker, I also mixed up Number and Decimal. Decimals are the floats, Numbers are the integers.
Here the working algorithm:
${start_dt
:toDate("yyyy-MM-dd'T'HH:mm:ssZ")
:format('MM','GMT')
:divide(3.0)
:plus(0.9)
:toNumber()}
Related
I use Laravel with vue/vuetify in frontend.
In a simple form, the user can set the settlement_factorwhich is a number with 2 decimals.
The field in the DB looks like
If I enter 1.68 the entry in the db is 1.68 but the system returns 1.68000000000002
Patch request value:
"settlement_factor": "1.68",
Response value
"settlement_factor": 1.6800000000000002,
But if I enter 1.67, the system returns 1.67 which is right:
Patch request value:
"settlement_factor": "1.67",
Response value
"settlement_factor": 1.67,
I use Laravel ressources to modify the response:
'settlement_factor' => $this->settlement_factor,
Why does the system change the value 1.68 to 1.68000000000002 but the other numbers are ok?
I have no Idea to find the error.
For a quick fix, I can add the round()function.
Don't use double for this. Double is a floating point number encoded
in 64 bits. The encoding of a decimal number in binary cannot always
be exact. 1.68 happens to be one of the numbers where the encoding is not exact so you see it displayed as 1.68000000000002.
Use Decimal (5,2) this would allow for 5 significant digits with 2 to the right of the decimal point. This would give you a range of 0 to 999.99. You can adjust these 2 number to fit the range you expect for the number. To match to the number you used, use Decimal (3,2) which gives you a range of 0.00 to 9.99.
Rounding will be managed by Decimal Type so you will not see the
encoding deviation like in Double.
I have a basic question about Stata. I have programming experience in R but I've started a new job where Stata is the main language. I'm currently diving into Stata on my own and sometimes it's hard to understand how to do simple things.
I've trying to get 5 random numbers between 3 and 50 but without success.
In R, any of these would work:
floor(runif(5, min=3, max=50))
16 39 11 11 5 # output
sample(3:50, 5, replace=TRUE)
28 13 5 36 19 # output
But I'm not sure how to do this in Stata, specifically how to return random numbers within the desired range (3:50). Any pointers would be appreciated. I found the runiform() function but I don't think I can get the same output.
Is this what you want?
set obs 5
generate rnum = runiform(3, 50)
You are basically creating a dataset first and then generating a variable with the desired properties.
Hi i have a weird problem with Erlang on Windows i am running 16B and WinXP.
I have the following code
-module(test).
-export([cost/1,total/1]).
cost(orange) ->
5;
cost(apple) ->
6.
total(L) ->
[cost(I) * Q || {I,Q} <- L].
I run it with
test:total([{orange,2}]).
and it gives me "\f"
changing cost(I) * Q to use -,+ or divide gives me a number.
I have no idea why multiply dosen't work in list comprehension. Running
[test:cost(I) * Q || {I,Q} <- [{orange,2}]]
in an erlang console and emacs mode also dosen't work but
test:cost(orange) * 2
does give me a number.
Any ideas why?
Note your cost/1 function returns a number. But total/1 returns a list (of numbers).
The results on that list are ok, this is just how erlang happens to display lists of small integers. See http://www.erlang.org/faq/problems.html 9.3
to see what I mean, try with larger numbers
test:total([{orange,2000}]).
Again, this is just a display issue, the value in the lists are what you expect. Try it:
[Value] = test:total([{orange,2}]).
Value.
A string is a list of integers. The value you're returning is a list of integers.
Erlang uses a simple heuristic for when to show something as a string, or as a list of integers: is it a flat list containing only numbers in the range {55,250}. (I made those numbers up, but it's something like that. If there are control characters or low characters, it bails.)
Since Erlang doesn't do this to tuples, tuples make it easy to see.
1> {72,101,108,108,111,44,32,83,116,101,112,104,101,110,46}.
{72,101,108,108,111,44,32,83,116,101,112,104,101,110,46}
2> [72,101,108,108,111,44,32,83,116,101,112,104,101,110,46].
"Hello, Stephen."
Erlang is just guessing wrongly what's inside the list.
HTH.
I don't have a lot of experience programming, let alone with Drools, but I am doing a project similar to the one of vehicle routing. Almost everything works fine, except for some moves, depending on the random seed.
The problem is that, once the Heuristic phase is done, sometimes the local search phase makes some strange moves, like the next one:
Heuristic phase solution:
day 1: place 1 -> place 2 -> place 3 -> place 4 -> place 5 -> place 6
day 2: place 7 -> place 8 -> place 9 -> place 10
Local search move: place 5 moved to day 2
Solution:
day 1: place 1 -> place 2 -> place 3 -> place 4
day 2: place 5 -> place 6
The rest of places is left with no day (in the example it would be vehicle), and they are left as an unanchored chain:
place 7 -> place 8 -> place 9 -> place 10 -> place 7 -> etc
So, when the program looks for the day of any of them, it enters an infinite loop. Obviously, the problem is not how to get out of that loop (I'm not that noob), it is how to avoid those movements.
I use the same solver configuration as the example (changing the solver class etc.) so I don't understand why it does those moves. I think that I should code my own Move class, but I can't find examples of how to code it, nor the MoveFactory. I leave the solver.xml in a code block.
Links or tips that would help me learn to code a Move and a MoveFactory class would be helpful, as well as configuration tips to avoid that (if there are any).
Anyway, thank you all for your time and effort.
<?xml version="1.0" encoding="UTF-8"?>
<solver>
<!--<environmentMode>DEBUG</environmentMode>-->
<environmentMode>PRODUCTION</environmentMode>
<solutionClass>org.tourgune.planificador.bean.Turista</solutionClass>
<planningEntityClass>org.tourgune.planificador.bean.PuntoInteres</planningEntityClass>
<scoreDirectorFactory>
<scoreDefinitionType>HARD_AND_SOFT</scoreDefinitionType>
<scoreDrl>/org/tourgune/planificador/core/planificadorScoreRules.drl</scoreDrl>
</scoreDirectorFactory>
<termination>
<maximumMinutesSpend>4</maximumMinutesSpend>
</termination>
<constructionHeuristic>
<constructionHeuristicType>FIRST_FIT</constructionHeuristicType>
</constructionHeuristic>
<localSearch>
<selector>
<selector>
<moveFactoryClass>org.drools.planner.core.move.generic.GenericChainedChangeMoveFactory</moveFactoryClass>
</selector>
<selector>
<moveFactoryClass>org.drools.planner.core.move.generic.GenericChainedChangePartMoveFactory</moveFactoryClass>
</selector>
<!-- TODO needs a GenericChainedSwapMoveFactory and probably even a GenericChainedSwapPartMoveFactory -->
</selector>
<acceptor>
<planningEntityTabuSize>10</planningEntityTabuSize>
</acceptor>
<forager>
<minimalAcceptedSelection>0</minimalAcceptedSelection>
</forager>
</localSearch>
<!--<localSearch>-->
<!--<selector>-->
<!--<selector>-->
<!--<moveFactoryClass>org.drools.planner.core.move.generic.GenericChainedChangeMoveFactory</moveFactoryClass>-->
<!--</selector>-->
<!--<selector>-->
<!--<moveFactoryClass>org.drools.planner.core.move.generic.GenericChainedChangePartMoveFactory</moveFactoryClass>-->
<!--</selector>-->
<!--</selector>-->
<!--<acceptor>-->
<!--<simulatedAnnealingStartingTemperature>10</simulatedAnnealingStartingTemperature>-->
<!--</acceptor>-->
<!--<forager>-->
<!--<minimalAcceptedSelection>4</minimalAcceptedSelection>-->
<!--</forager>-->
<!--</localSearch>-->
</solver>
Upgrade to 5.5.0.Final first, so you can just use <changeMoveSelector/> instead of those generic factories. Follow the upgrade recipe txt.
If you still have the problem then, enable DEBUG to detect score corruption (usually caused by the clone method or hacky score rules). OptaPlanner (= Drools Planner) 6.0 will make it easier to write score rules and make it much less likely that you face score corruption.
How does Mathematica decide when to round numbers in its output? For example,
giving the input
250000.5
gives the output
2500001
While
25000.5
is indeed printed as
25000.5
N[] isn't helpful here either, I need to use NumberForm[] to get it to actually print 250000.5 as 250000.5
I'm a Mathematica newbie, and I'm sure its ridiculously easy to control this threshold for when it starts ignoring decimals in its output, but could somebody please point me in the right direction?
another option for you to try, you can go to options and change the default PrintPrecision from 6 to say 16, and now you will see that it will print what you typed above
after I changed that to 16 (click on the field itself, and type 16 into the field to replace the 6, and hit return), then
Nasser is correct that PrintPrecision is the right setting.
You have a number of options for its use. You can set it Globally or for the specific Notebook using the Options Inspector. You can also use it directly with Style:
Style[250000.5, PrintPrecision -> 10]
250000.5
You can set it temporarily for one session like this:
SetOptions[$FrontEndSession, PrintPrecision -> 10]
Finally you can set it using Style Sheets (select cell type Output).
In the default TraditionalForm and StandardForm output modes Mathematica only shows a certain number of most significant digits. You can use InputForm to get the full precision number.