9,770 karma · joined October 13, 2012
How would that work? You have the AI explain its reasoning - and trust that this is accurate - and then you decide whether that is acceptable behavior. If not, you ban the AI from driving because it will deterministically or at least statistically repeat the same behavior in similar scenarios? Fine, I guess, that will at least prevent additional harm. But is this really all that you want? The AI - at least as we have them today - did not create itself and choose any of its behaviors, the developers did that. Would you not want to hold them responsible if they did not properly test the AI before releasing it, if they cut corners during development? In the same way you might hold parents responsible for the action of their children in certain circumstances?
We usually use UUIDs for this type of object but we have to send those objects to the legacy system XYZ, which only supports IDs with up to sixteen characters and is case insensitive, so we generate sixteen character random alphanumeric strings with uppercase letters which provides 82 bits of entropy.
Could you go deeper? Sure. Why do we have to send those objects to XYZ? Why does the legacy system still exist? Why does it not support UUIDs? Why is there no secondary key specifically for that system? Why are we using UUIDs?
But most likely you do not have to spell all those out. The point of a why is to explain why something is not what one would expect, you explain on top of some common knowledge. Everyone involved might know what XYZ does and why some objects have to get send there. If not, that is probably written down elsewhere. Why is the system using UUIDs? Maybe written down in the design for the persistence layer.
[1] https://images.blackmagicdesign.com/images/products/davincir...
[1] https://store.steampowered.com/app/473950/Manifold_Garden/
[1] https://en.wikipedia.org/wiki/Miegakure
This still measures the time of day in seconds since midnight. It still encodes the number of seconds into the common base 60 system of hours, minutes, and seconds. It still encodes the base 60 digits as base 10 numerals. The only differences are the choice of digits - regular polygons instead of an established set of digits like the Arabic digits - and the writing direction - increasing in scale, radially outwards instead of horizontally or vertically - defining the positional value of each digit.
Simply a dot moving around a circle once per day would have abandoned way more cultural assumption than this. Of course at the cost of making it harder to read precisely and looking less fancy.
This combination of base 60 and base 10 can also be understood as a multi-base numeral system. 12:34:56 can be understood as 123456 with non-uniform positional values 1, 10, 60, 600, 3,600, 36,000 from right to left directly yielding the number of seconds since midnight as 1 x 36,000 + 2 x 3,600 + 3 x 600 + 4 x 60 + 5 x 10 + 6 x 1 = 45,296.
The polygon numerals are actually similar to Babylonian cuneiform numerals [1]. They use a positional system just like Hindu-Arabic numerals with the positional value increasing by a factor of the base - 10 for Hindu-Arabic numerals, 60 for Babylonian cuneiform numerals - from right to left but there are not different digits 0 to 9 - or actually 0 to 59 because of base 60 - but they just repeat a symbol for one (I) [2] n times like the Roman numerals do. This IIII II is 42 but in base 60, so 4 x 60^1 + 2 x 60^0 = 242. Ignoring the edges, the polygon numerals express the digit value by repeating a vertex 0 to 9 times and each scale increase of the polygon adds a factor according to the 60 and 10 multi-base representation described above.
[1] https://en.wikipedia.org/wiki/Babylonian_cuneiform_numerals
[2] Because repeating the symbol for one (I) up to 59 times is inconvenient, they have a symbol for ten (<) as a shortcut, just as the Roman numerals have V for IIIII. <II <<<IIII is (1 x 10 + 2 x 1) x 60^1 + (3 x 10 + 4 x 1) x 60^0 = 754.
Microsoft had a remotely similar tool named Pex [1] but instead of randomly generating inputs, it instrumented the code to enable executing the code also symbolically and then used their Z3 theorem proofer to systematically find inputs to make all encountered conditions either true or false and with that incrementally explore all possible execution paths. If I remember correctly, it then generated a unit test for each discovered input with the corresponding output and you could then judge if the output is what you expected.
[1] https://www.microsoft.com/en-us/research/publication/pex-whi...
It is not an independence war, it is colonialization and occupation. And the Zionists at the time knew that and used this terminology themselves. 1948 was not an independence war, it was the preliminary culmination of the attempt to occupy and annex Palestine into a Jewish state against the resistance of the Palestinians. And the residence against this illegal act has continued to this day.
[1] I would however argue the later thing is more rare as it requires competent developers, however this still does not preclude some misunderstanding of the requirements.
EDIT: My bad, the code eventually calls into dedicated functions from database.ts, so those 200 lines are mostly just validation and error handling. I really just skimmed the code and the amount of it made me assume that it actually implements the functionality somewhere in there.
Example, Agent.ts, line 93, function createManageKnowledgeTool() [1]. I would have expected something like the following and not almost 200 lines of code implementing everything in place. This also uses two stores of some sort - memory and scratchpad - and they are also not abstracted out, upsert and delete deal with both kinds directly.
switch (action)
{
case "help":
return handleHelpAction(arguments);
case "upsert":
return handleUpsertAction(arguments);
case "delete":
return handleDeleteAction(arguments);
default:
return handleUnknowAction(arguments);
}
But what if we discover that our universe is made from tiny voxels or something like that, that will be undeniable evidence, right? Wrong! Who says that real universes are not made of tiny voxels? It could be [1] the other way around, maybe real universes are discrete but their universe simulations are continuous, in which case the lack of tiny voxels in our universe would be the smoking gun evidence for being in a simulation.
[1] This is meant as an example, I have no idea if one can actually come up with a discrete universe that admits continuous simulations, which probably should also be efficient in some sense.
So what you really want is to be in a state that will make you chose one box and you want to already be in that state at the time the predictor makes its predictions because the predictor will see this and place the million dollars into the second box. And as we have already said, you can not chose to take two boxes afterwards as that would contradict the existence of the predictor.