Update, 5/14/2023:  Version 3.2

Update, 5/11/2023:  Version 3.1.  Original: Version 2

I wrote a javascript calculator while I was waiting for something the other day.  Here it is:

Permalink: Here

Technical Details

• Single, self-contained HTML file with embedded CSS and Javascript.
• The display width is configurable via a variable – currently 20 digits
• The top line is a “register” – normally this would be hidden on a desktop calculator.  The two variables, “register” and “display” are global, which simplifies the architecture.
• The buttons are created using a function
• Binary math functions are performed by a wrapper that sanitizes the input values and then performs a callback to the underlying math operation – the pointer to the callback function is passed via onclick.
• Unary math functions are basically handled the same as binary operations, where onclick calls a wrapper, and the wrapper executes a callback.

To Do

(Updated, 5/11/2023)

• Add MS, MR, M+, and M-, which will require a separate register.
• Add a configurable table of constants.
• Tool tips with enable/disable button.
• Hex and binary functions, although these might be a separate calculator
  Update:  I think I will just make a dedicated programming calculator the next time I’m bored :-)

Funny Story about 3.1 vs 3.2

I uploaded version 3.1, and patted myself on the back for having done such a great job.  Right-click, save as HTML, fire it up in Chrome, and…everything was rendering twice.

What happened??

The UI is dynamic, but the saved version of the page had BOTH a static copy of the dynamically-generated HTML, as well as the javascript code to dynamically generate the HTML.  So every UI element was rendered TWICE.  Worse, if you modify the Javascript at the top of the file to alter the constants or the display size, you would have one copy that’s correct because it’s dynamic, but the static copy would still be wrong.

Interestingly, if you View Source and save from there, it won’t have that problem, but that’s not what I was after.

To fix this, I changed from document.write to using extra SPANs for each block of UI elements, and setting innerHTML.  Despite the fact that saving the file includes a static copy of the HTML, the dynamic code simply overwrites it each time the page is loaded.  So if you change a Javascript variable and reload, the dynamic code blows away the static HTML and replaces it with a correct version.

Do you like it?  Feel free to copy it.  Click the permalink.  Then right-click the calculator, and select “Save as html”.

Ideas or suggestions?  Please feel free to leave me a comment.

After 7 months of continuous issues, I think I finally beat the problems with the front gate, but the way I did it might surprise you.

Continue Reading

In 2015, I wrote this post: Justin’s Rules for Buying a House.

These were things that I had learned when I was shopping for a house in 2002, and solidified in to a tangible list when a couple of friends of mine were house shopping in 2015.

After shopping for a house in 2019 and moving out to the country, here are a few more things I’ve added to my list.

Continue Reading

Updated to v1.2 on 1/3/2023.

Although it’s widely agreed that field-level data encryption provides the best protection against data breaches, it also limits an application’s ability to perform ranged searches, where an inequality comparison is performed against search terms.

Although there are existing strategies which use search trees, these depend on complex key management schemes, or trees with fixed intervals.

Another common approach is to assign artificial search keys, but the general problem with this approach is that it can result in information disclosure as well as key collisions. If the keys are regularly-spaced, this can lead to an inference about the underlying data values, and if the spacing is too narrow, this can lead to insufficient search keys when presented with a large quantity of data values for given key interval.

In the scheme proposed herein, a binary tree is used to generate integer search keys, called comparators, that are non-sequential but maintain the same ordinal relationship as the underlying data.  Because comparators have no fixed relationship to each other, they don’t leak any information, but because they maintain an ordinal relationship, they can be searched with a ranged query.

Click here to view or download:

Searching Encrypted Data