How do you print nicely in LEDA - visual-studio

How do you print 'nicely' in LEDA?
I am looking for the equivalent to
fixed
setprecision(3)

I have got a little further with this.
There is a difference between precision and output precision.
I can set LEDA's output precision with e.g bigfloat::set_output_precision(4);
but I still do not know what LEDA's equivalent to fixed is.
Also, I do not know what the latest LEDA of todouble is
I have tried mu.todouble() where mu is declared as a bigfloat, but I get a compiler error

A further answer is mu.to_double()

Related

WQL/SCCM - Comparing version numbers correctly (less than...)

I'm having a problem with this part of a SCCM WQL query looking for "less than version 75.0.3770.80":
... where SMS_G_System_ADD_REMOVE_PROGRAMS.Version < "75.0.3770.80"
If i'm not mistaken this is the good old problem seen before in other scenarios (file names for example) where it will return objects with version number :
75.0.3770.142
Because in it's logic "of course" .142 is "less than" .80 because .1 is less than .8. It doesn't treat it as "142 versus 80" but "1 versus 8"
Is there any way I can work around this? I'm getting a lot of false positives with this query and need to filter them out. If it was straight Powershell I could cast it as [version] but in SCCM, is it at all possible to do this comparison?
If only the last part of the version number is different, we could use the following one.
... where SMS_G_System_ADD_REMOVE_PROGRAMS.Version like "75.0.3770.[1-7][0-9]"
or ... like "75.0.3770.[0-9]"
Best Regards,
Ray
Ended up using SMS_G_System_ADD_REMOVE_PROGRAMS.Version < "75.0.3770"
This goes wrongs if the first version nr reach 100.
Better something like this
SMS_G_System_ADD_REMOVE_PROGRAMS.Version like "75.0.%" and
SMS_G_System_ADD_REMOVE_PROGRAMS.Version < "75.0.3770

socket.io with strange timestamp format (?)

I see requests to socket.io containing parameter t to be like LZywzeV, LZz5lk7 and similar.
All examples that i found so far used second- or millisecond-based UNIX timestamps.
Has anyone ever seen a timestamp format like this? (It is not base64-encoded).
I started looking a site that uses Socket.io today, and got the same problem, trying to look for the protocol definition was useless.
I figured this format is something called yeast
TBH, really don't know why people invent this sort of things instead of use
base64(timestamp.getBytes())
pseudocode instead.
A yeast decode algorithm in Python is as follow:
from datetime import datetime
a='0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-_'
b={a[i]: i for i in range(len(a))}
c=0
for d in "LZywzeV":
c=c*64+b[d]
print(c)
print(datetime.fromtimestamp(c/1000))
The output of that code is:
1481712065055
2016-12-14 07:41:05
to #jeremoquai:
It is easy, is matter of invert the algorithm:
def yeast(d):
r=""
while d!=0:
r='0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-_'[d&63]+r
d>>=6
return r
so, if you run
yeast(1481712065055)
it returns LZywzeV

Swift Compiler performance

I got this statement in Swift code which produces an error when executing in playground:
let colors: [String: [Float]] = ["skyBlue" : [240.0/255.0, 248.0/255.0, 255.0/255.0,1.0],
"cWhite" : [250.0/255.0, 250.0/255.0, 250.0/255.0, 1.0]]
The error is : expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions
Then I changed the arrays element type to Double which just works fine.
However I am asking myself why this happens ?
As I said using Double it works just fine. So my guess is that Swift tries to guess the type and therefore Double works better in this example than Float.
Similar issues have been reported before, and (as I understand it) the problem is the automatic type inference for "complicated" expressions. You should file a bug report at Apple.
It compiles with a dictionary of one color, but not with two.
In this concrete case, you can work around it by converting each number in the array to a Float explicitly:
let colors = [
"skyBlue" : [Float(240.0/255.0), Float(248.0/255.0), Float(255.0/255.0),Float(1.0)],
"cWhite" : [Float(250.0/255.0), Float(250.0/255.0), Float(250.0/255.0), Float(1.0)]
]

I need a data type big enough to hold pow(80,7)

Im using pow from cmath.h for the power of function. Im using the line of code pow(80,7). Int and long are to small to give me the right value. Im going to use printf or cout to display the result
what data type can I use
Maybe you should have a look at GNU GMP (https://gmplib.org/).
HTH!

MATLAB - image huffman encoding

I have a homework in which i have to convert some images to grayscale and compress them using huffman encoding. I converted them to grayscale and then i tried to compress them but i get an error. I used the code i found here.
Here is the code i'm using:
A=imread('Gray\36.png');
[symbols,p]=hist(A,unique(A))
p=p/sum(p)
[dict,avglen]=huffmandict(symbols,p)
comp=huffmanenco(A,dict)
This is the error i get. It occurs at the second line.
Error using eps
Class must be 'single' or 'double'.
Error in hist (line 90)
bins = xx + eps(xx);
What am i doing wrong?
Thanks.
P.S. how can i find the compression ratio for each image?
The problem is that when you specify the bin locations (the second input argument of 'hist'), they need to be single or double. The vector A itself does not, though. That's nice because sometimes you don't want to convert your whole dataset from an integer type to floating precision. This will fix your code:
[symbols,p]=hist(A,double(unique(A)))
Click here to see this issue is discussed more in detail.
first, try :
whos A
Seems like its type must be single or double. If not, just do A = double(A) after the imread line. Should work that way, however I'm surprised hist is not doing the conversion...
[EDIT] I have just tested it, and I am right, hist won't work in uint8, but it's okay as soon as I convert my image to double.

Resources