What is the unit of mosek.dparam.optimizer_max_time parameter. I mean does it expects the input value in: seconds / milliseconds?
Would it be safe to assume the time units is always seconds, wherever the documentation does not explicitly specifies (Eg. mosek.dparam.mio_max_time , ...) ?
Related
I am looking to add a variable to count from 1 to 217 every hour in AnyLogic, in order to use as a choice condition to set a parameters row reference.
I am assuming I either need to use an event or a state chart however I am really struggling with the exact and cannot find anything online.
If you have any tips please let me know, any help would be appreciated
Thank you,
Tash
A state machine isn't necessary in this case as this can be achieve using a calculation or a timed event. AnyLogic has time() function which returns time since model start as a double in model time units of measurements.
For example: if model time units is seconds and it has been running for 2hr 2min 10sec then time(SECOND) will return 7330.0 (it is always a double value). 1/217th of an hour corresponds to about 3600/217 = 16.58 seconds. Also, java has a handy function Math.floor() which rounds down a double value, so Math.floor(8.37) = 8.0.
Assembling it all together:
// how many full hours have elapsed from the start of the model
double fullHrsFromStart = Math.floor(time(HOUR));
// how many seconds have elapsed in the current model hour
double secondsInCurrentHour = time(SECOND) - fullHrsFromStart * 3600.0;
// how many full 16.58 (1/217th of an hour) intervals have elapsed
int fullIntervals = (int)(secondsInCurrentHour / 16.58);
This can be packaged into a function and called any time and it is pretty fast.
Alternatively: an Event can be created which increments some count by 1 every 16.58 seconds and ten resets it back to 0 when the count reaches 217.
I tried setting the timeouts small to force the failures to see what happens:
ClientBuilder.newBuilder()
.readTimeout(1, TimeUnit.NANOSECONDS)
.connectTimeout(1, TimeUnit.NANOSECONDS)
But the code still seems to hang for what feels like the default timeout values.
readTimeout and connectTimeout both accept a TimeUnit parameter so it makes sense the NANOSECONDS would be ok right?
The javadoc for these both read:
Value 0 represents infinity. Negative values are not allowed.
And these are internally converted to MILLISECONDS via TimeUnit.convert which states:
Conversions from finer to coarser granularities truncate, so lose precision.
That is what is happening here. TimeUnit.convert even has an example:
For example, converting {#code 999} milliseconds to seconds results in {#code 0}.
Which would be a similar problem for converting 1 nanosecond to milliseconds resulting in 0.
And 0 is infinity... that is, the operating system default timeouts.
Clearly this is obvious, but none of the Javadocs indicate that the specified times will be internally converted into MILLISECONDS and to beware of losing precision.
And I've wasted days wondering why this wasn't working, when I should have remembered from years of network programming milliseconds are the default units.
According to ABAP Documentation, the command WAIT UP TO x SECONDS needs an operand of type i. However, I'd like to WAIT UP TO x Milliseconds or something similar. Neither official documentation nor several other forum posts have been helpful thus far.
Is there any way to specify a wait for a fraction of a second?
You can simply pass a decimal value like:
WAIT UP TO '0.5' SECONDS
or something like:
WAIT UP TO '0.01' SECONDS
See also How to make an abap program pause.
If you want to avoid implicit commit with WAIT UP TO, create a simple RFC function:
FUNCTION ZSLEEP .
*"--------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(DURATION) TYPE SDURATION_SECONDS
*"--------------------------------------------------------------------
* To wait 50 milliseconds write this:
* DATA duration TYPE sduration_seconds VALUE '0.050'.
* CALL FUNCTION 'ZSLEEP' DESTINATION 'NONE' KEEPING LOGICAL UNIT OF WORK EXPORTING duration = duration.
WAIT UP TO duration SECONDS.
ENDFUNCTION.
I've just solved it like this:
DATA: timestart TYPE timestampl,
timeend TYPE timestampl,
millisecs TYPE timestampl,
imilli TYPE i VALUE 200.
GET TIME STAMP FIELD timestart.
millisecs = imilli / 1000.
timestart = timestart + millisecs.
DO.
GET TIME STAMP FIELD timeend.
IF timestart < timeend.
EXIT.
ENDIF.
ENDDO.
WRITE timeend.
If I now rewrite this as a function taking an integer as an import parameter (in place of imilli) I'll - to my knowledge - have exactly what I wanted.
I'll leave this up for a little before tagging it as the correct answer in the hopes that someone may have a better / more elegant solution.
Without asking about the requirement, 2 ways to do this are
GET RUN TIME
where SET RUN TIME CLOCK RESOLUTION can be important.
or
GET TIME STAMP using a target field TIMESTAMPL
Do not use WAIT UP TO for fine time frames due to the Workprocess switching.
Wait also carries other side effects not immediately obvious.
I am not sure if this is a bug. But I've been playing with big and I cant understand why this code works this way:
https://carc.in/#/r/2w96
Code
require "big"
x = BigInt.new(1<<30) * (1<<30) * (1<<30)
puts "BigInt: #{x}"
x = BigFloat.new(1<<30) * (1<<30) * (1<<30)
puts "BigFloat: #{x}"
puts "BigInt from BigFloat: #{x.to_big_i}"
Output
BigInt: 1237940039285380274899124224
BigFloat: 1237940039285380274900000000
BigInt from BigFloat: 1237940039285380274899124224
First I though that BigFloat requires to change BigFloat.default_precision to work with bigger number. But from this code it looks like it only matters when trying to output #to_s value.
Same with precision of BigFloat set to 1024 (https://carc.in/#/r/2w98):
Output
BigInt: 1237940039285380274899124224
BigFloat: 1237940039285380274899124224
BigInt from BigFloat: 1237940039285380274899124224
BigFloat.to_s uses LibGMP.mpf_get_str(nil, out expptr, 10, 0, self). Where GMP is saying:
mpf_get_str (char *str, mp_exp_t *expptr, int base, size_t n_digits, const mpf_t op)
Convert op to a string of digits in base base. The base argument may vary from 2 to 62 or from -2 to -36. Up to n_digits digits will be generated. Trailing zeros are not returned. No more digits than can be accurately represented by op are ever generated. If n_digits is 0 then that accurate maximum number of digits are generated.
Thanks.
In GMP (it applies to all languages not just Crystal), integers (C mpz_t, Crystal BigInt) and floats (C mpf_t, Crystal BigFloat) have separate default precision.
Also, note that using an explicit precision is better than setting a default one, because the default precision might not be reentrant (it depends on a configure-time switch). Also, if someone reads only a part of your code, they may skip the part with setting the default precision and assume a wrong one. Although I do not know the Crystal binding well, I assume that such functionality is exposed somewhere.
The zero parameter passed to mpf_get_str means to guess the value from the precision. I know the number of significant digits is proportional and close to precision / log2(10). Floating point numbers have finite precision. In that case, it was not the mpf_get_str call which made the last digits zero - it was the internal representation that did not keep such data. It looks like your (default) precision is too small to store all the necessary digits.
To summarize, there are two solutions:
Set a global default precision. Although this approach will work, it will require to either change the default precision frequently, or use one in the whole program. Both ways, the approach with the default precision is a form of procrastination which is going to have its vengeance later.
Set a precision on variable basis. This is a better solution than the former. Although it requires more code (1-2 more lines per variable initialization), it is going to pay back later. For example, in a space object tracking system, the physics calculations have to be super-precise, but other systems could use lower precision numbers for speed and memory saving.
I am still unsure what made the conversion BigFloat --> BigInt yield the missing digits.
NSTimeInterval is a double, thus it cannot take a nil, and 0 represents something that should happen immediately. Is there a constant that means "never"... or an astronomically huge value, or should I use -1?
As suggested by s.bandara, use a very large number to treat a time interval as "infinite" or "never".
DBL_MAX is the largest value a double can hold. This macro is declared in float.h:
#define DBL_MAX (9.999999999999999e999)
In Swift, use TimeInterval.infinity. For example, in SwiftUI to conditionally enable a timeline view to update every second or never, use:
TimelineView(.periodic(from: start, by: isRunning ? 1 : .infinity))