The SEAL library (v 2.1.3) offers an automatic parameter selection tool to help choose the optimal parameter values for a given evaluation function of the ciphertexts.
The current version of SEAL, however, only supports the Integer Encoder. In other words, it only supports cases where the inputs are encryptions of integers.
Is there a way to extend automatic parameter selection tool in SEAL to cover the FractionalEncoder? In other words, is there a way to adapt the automatic parameter selection tool to handle cases where the inputs to the evaluation function are rational numbers?
Related
In Modelica Standard Library, the unit of SpecificEnergy and SpecificEnthalpy is "J/kg", but I'd like to use "kJ/kg" as the display unit, my first thought is to modify the Modelica Standard Library, but I am not sure if it will cause unexpectable issues, so I want to find a way to customize my own Modelica Standard Library. In this way, I could choose to use my own version or the standard one.
My question is: Is there some way like this?
In addition to using defineUnitConversion there is another possibility for prefixed units such as "kJ/kg" or "MJ/kg": just define a variable with that displayUnit in the model by creating e.g.,
SpecificEnthalphy myEnthalpy(displayUnit="MJ/kg")=...;
and then simulating the model.
No need to specify a conversion factor in this case (it is found automatically).
There are multiple possibilities to extend the unit conversions in Dymola. Probably the best is the one for the question asked is mentioned by Hans Olsson below, but you can as well
Create a function like this:
function unitConversions "Define unit conversions, which are currently not pre-defined by Dymola"
extends DymolaModels.Icons.Basic.Function;
algorithm
defineUnitConversion("J/kg", "kJ/kg", 1e-3);
// more conversions could be added here
end unitConversions;
After the function is executed, the conversion should be available for the current session of Dymola. So you need to run the function manually every time Dymola is started. This is actually one reason I asked this question - but there seems to be no answer until now.
As an alternative, you can modify E:\[Dymola_InstallPath]\insert\displayunit.mos and add the same line. This will be usable until you install a new version of Dymola, for which you will have to do the same modification...
The Rust standard library has the std::mem::uninitialized function, which allows you to manually create an undefined (and possible invalid) value of any type. This essentially maps to LLVM's undef. I was wondering if Swift had an equivalent, as I haven't been able to find one skimming through the standard library documentation.
Motivation
The primary use for this is to bypass the compiler's normal memory initialization checks when they prove imprecise. For instance, you might want to initialize some members of a structure using methods (or in Swift's case, property setters), which the compiler usually would not allow you to do. Using dummy values works, but that's potentially less efficient (if the optimizer cannot prove that the dummy is meaningless).
In Rust, uninitialized values are treated as initialized by the initialization checker, but as uninitialized by LLVM, leading to more reliable optimization. Since the Swift compiler is also built atop LLVM, it seems like something the Swift compiler should also be able to support.
My Specific Use Case
I have a struct which encapsulates a set of bit fields compacted into one machine word (an unsigned integer type). The struct type provides a safe and convenient interface for reading and modifying the individual fields, through computed properties.
I also have an initializer that takes the relevant field values as parameters. I could initialize the underlying machine word using the same bitwise operations that the computed properties use (in which case I would be repeating myself), or I could initialize it simply by setting the values of the computed properties.
Currently, Swift does not support using computed properties before self has been fully initialized. It's also unlikely Swift will ever support this case, since the computed property setters modify the existing machine word, which would require it to already be initialized, at least as far as Swift is concerned. Only I know that all my setters, in concert, will fully initialize that machine word.
My current solution is to simply initialize the machine word to 0, and then run the setters. Since a constant 0 is trivially absorbed into the bitwise | chain that combines the fields, there's no CPU time lost, but that's always going to be the case. This is the kind of situation where, in Rust, I would have used an uninitialized value to express my intent to the optimizer.
I have to write a Level-2 S-Function in Matlab code (C is not viable) which takes in some parameters and uses them alone and in combination.
First I tried tunable parameters, but unfortunately I haven't succeded in tuning them (the documentation doesn't tell how to set_param for this purpose).
Then I have bumped into documentation of Run-Time parameters that says
The value of a run-time parameter that corresponds to multiple dialog
parameters is typically a function of the values of the dialog
parameters.
So I deduced that a runtime parameter would suit well, but the same documentation doesn't say how to tune and access them from a Matlab S-function, only from a C one.
Also, in in this page is documented a RuntimePrm object that seems similar to DialogPrm, but trying to write the values result in an error.
Is there any way to "cache" parameter combinations without using DWorks, which would affect subsequent linearization with fake states?
I want to build a Boolean expression builder in gwt. Something like the following:-
Let's say that the Boolean expression allows only a finite number of unique operands. These operands could take arguments if necessary
E.g.
IsSunny("today") AND IsNotRaining("evening")
IsLeapYear("2012") AND IsFullMoon("today")
There is only a finite set of operands. E.g. IsSunny, IsNotRaining, IsLeapYear, IsFullMoon.
I want to build a GWT UI that allows the client to build such Boolean expressions quickly.
Only the predefined set of operands are supported. Each operand can have different number of arguments and the UI ,use enforce the type and number of arguments. Parenthesis is also allowed.
What would be a good way to build such an UI?
Does GWT have any in built support for it?
Thanks,
Ajay
WARNING: I'm the author of this project but... http://redquerybuilder.appspot.com/ is sort of similar and is written in GWT.
At the moment I've only published the JS friendly version but I'd be happy to make a GWT version available.
Is aimed towards SQL but it is the only thing in this direction that I know of.
I'm up for sharing tips if you want to write it from scratch.
Goal: I want to write an X86_64 assembler. Note: marked as community wiki
Background: I'm familiar with C. I've written MIPS assembly before. I've written some x86 assembly. However, I want to write an x86_64 assembler -- it should output machine code that I can jump to and start executing (like in a JIT).
Question is: what is the best way to approach this? I realize this problem looks kind large to tackle. I want to start out with a basic minimum set:
Load into register
Arithmetric ops on registers (just integers is fine, no need to mess with FPU yet)
Conditionals
Jumps
Just a basic set to make it Turing complete. Anyone done this? Suggestions / resources?
An assembler, like any other "compiler", is best written as a lexical analyser feeding into a language grammar processor.
Assembly language is usually easier than the regular compiled languages since you don't need to worry about constructs crossing line boundaries and the format is usually fixed.
I wrote an assembler for a (fictional) CPU some two years ago for educational purposes and it basically treated each line as:
optional label (e.g., :loop).
operation (e.g., mov).
operands (e.g., ax,$1).
The easiest way to do it is to ensure that tokens are easily distinguishable.
That's why I made the rule that labels had to begin with : - it made the analysis of the line so much easier. The process for handling a line was:
strip off comments (first ; outside a string to end of line).
extract label if present.
first word is then the operation.
rest are the operands.
You can easily insist that different operands have special markers as well, to make your life easier. All this is assuming you have control over the input format. If you're required to use Intel or AT&T format, it's a little more difficult.
The way I approached it is that there was a simple per-operation function that got called (e.g., doJmp, doCall, doRet) and that function decided on what was allowed in the operands.
For example, doCall only allows a numeric or label, doRet allows nothing.
For example, here's a code segment from the encInstr function:
private static MultiRet encInstr(
boolean ignoreVars,
String opcode,
String operands)
{
if (opcode.length() == 0) return hlprNone(ignoreVars);
if (opcode.equals("defb")) return hlprByte(ignoreVars,operands);
if (opcode.equals("defbr")) return hlprByteR(ignoreVars,operands);
if (opcode.equals("defs")) return hlprString(ignoreVars,operands);
if (opcode.equals("defw")) return hlprWord(ignoreVars,operands);
if (opcode.equals("defwr")) return hlprWordR(ignoreVars,operands);
if (opcode.equals("equ")) return hlprNone(ignoreVars);
if (opcode.equals("org")) return hlprNone(ignoreVars);
if (opcode.equals("adc")) return hlprTwoReg(ignoreVars,0x0a,operands);
if (opcode.equals("add")) return hlprTwoReg(ignoreVars,0x09,operands);
if (opcode.equals("and")) return hlprTwoReg(ignoreVars,0x0d,operands);
The hlpr... functions simply took the operands and returned a byte array containing the instructions. They're useful when many operations have similar operand requirements, such as adc,addandand` all requiring two register operands in the above case (the second parameter controlled what opcode was returned for the instruction).
By making the types of operands easily distinguishable, you can check what operands are provided, whether they are legal and which byte sequences to generate. The separation of operations into their own functions provides for a nice logical structure.
In addition, most CPUs follow a reasonably logical translation from opcode to operation (to make the chip designers lives easier) so there will be very similar calculations on all opcodes that allow, for example, indexed addressing.
In order to properly create code in a CPU that allows variable-length instructions, you're best of doing it in two passes.
In the first pass, don't generate code, just generate the lengths of instructions. This allows you to assign values to all labels as you encounter them. The second pass will generate the code and can fill in references to those labels since their values are known. The ignoreVars in that code segment above was used for this purpose (byte sequences of code were returned so we could know the length but any references to symbols just used 0).
Not to discourage you, but there are already many assemblers with various bells and whistles. Please consider contributing to an existing open source project like elftoolchain.