Proposal: render long decimals differently after X characters

[schanzer]

Displaying more precision gives users diminishing returns after the first 8-10 digits, and instead becomes a nuisance. Consider a table with several rational columns - scrolling to see all the columns in the table can become arduous!

I wonder what everyone thinks about setting a cutoff for display, and then eliding the rest with an ellipsis? Or, in the case of rationals, rendering the fraction instead?

[shriram]

Our output values are not static. Thus, one could imagine cutting off after, say, two decimal places and having a … which is clickable to reveal the next/rest. This would be useful in general, not only in tables.

The problem is in a table, you could have a hundred rows; if you click to expand one, should all click to expand? This seems therefore more like something you can expand at both the local and columnar levels. Similarly, switching output between decimals and fractions — which, again, we can already do — should also be something we can do at the columnar level.

Does the columnar setting override anything you've already done to an individual cell in the column? Probably. Not optimal but too much state in output is bad.

[blerner]

I'm not terribly a fan of this, since I think it doesn't really solve a problem and can easily cause more confusion.

• In a fairly-natural simulation we wrote a while back, we very quickly started getting inordinately precise values (because the rational numbers were multiplied on every tick). Even if we preferred to show a fraction, that fraction itself was dozens of digits wide in lowest-terms anyway. Space was not saved by toggling between decimal expansion and fractional renderings. (See https://github.com/brownplt/pyret-lang/issues/1118 for discussion.)

• Choosing an arbitrary cutoff, especially a small one like suggested above, is all-but-guaranteed to trigger science teachers who want to talk about significant digits.

• Doing this can easily lead to very confusing output:

  num-sqrt(2) + num-sqrt(3) is-roughly 3.1415926

  will fail, but show "The left side was 3.14..., the right side was 3.14...", which sure look equal, and then we'll repeatedly have to explain that those dots are clickable, and do not mean that the number ends where it appears to end, and you can't be lazy and assume only two digits suffice, and and and... Semantically, I'd prefer to reserve a trailing ellipsis for roughnums rather than for long but exact rationals. (We have a PR https://github.com/brownplt/pyret-lang/pull/1199 languishing to this effect, and there were some unresolved design and implementation issues there.)

I recognize that these complaints are along the lines of "perfect being the enemy of the good", but I would need some more persuading here to want to change how our numbers work.

I would almost rather solve this via CSS, and style things such that all decimal-displayed numbers get a max-width: ###em of some number of characters, with an overflow-x: scroll to obscure the remaining digits while still rendering them all.

[schanzer]

I’m convinced :)

[shriram]

Can we close this after there's a logged request for Ben's suggestion?

[blerner]

I'm not particularly a fan of my suggestion either: it's not accessible, it's unintuitive, and it is surprising. The only thing it has going for it is being better (in my opinion) than eliding digits, but I think it's worse than showing the digits in the first place.

[sorawee]

The problem is in a table, you could have a hundred rows; if you click to expand one, should all click to expand? This seems therefore more like something you can expand at both the local and columnar levels. Similarly, switching output between decimals and fractions — which, again, we can already do — should also be something we can do at the columnar level.

Why only a column and not the whole REPL? If it applies globally, we can do something like this:

(sorry for my crappy Paint-fu)

When the checkbox is ticked, the control is enabled, allowing you to customize the precision. When the checkbox is unticked, the control is disabled, and the display would show full precision.

[schanzer]

+1

This would actually be trivial to implement via CSS. All we need is a class name attached to the editor, which is toggled on or off based on some UI elements.

[blerner]

-1 I don't much like the idea of cluttering the Bonnie menu with additional controls (and I really don't like the look of this particular UI of a check box, two buttons and a label all crammed on a line -- it's creative and it gets the job done, but it feels awkward. I'm not a fan of Chrome's menu that has five or six controls on a single menu-item line, either...). But again, we have to be cautious of screwing up screen-readers, scrollability, working copy-paste, and predictability. (Consider that this will be another point of variation that teachers will need to be trained on, when looking at student screens, "No Johnnie, you can't fool me that Pyret is wrong, since you've hidden some of the output...")

[sorawee]

and I really don't like the look of this particular UI of a check box, two buttons and a label all crammed on a line

Then, change it to just a menu item "Decimal Precision (5 digits)". Clicking it will open up a modal window, with controls that are not crammed into a line.

I don't much like the idea of cluttering the Bonnie menu with additional controls

What about adding a "Preferences" menu item (which will open up a modal window)? Then, things like "Contribute detailed usage information" could also be moved there so that the Bonnie menu is not cluttered?

(I think it makes sense to leave font size in the Bonnie menu, since it's likely used a lot)

[schanzer]

Before we talk about what kind of button it should be and where it should be located, I want to first make sure we have actually reached some consensus here.

@blerner , are you saying that you would be OK with this kind of solution, provided we can agree on a design for the user interface?

[blerner]

No, my opinion hasn't really changed: I'm saying I don't think this is necessary and I don't think it's solving a problem that needs solving, and has the potential to cause new confusions. But if everyone wants to do this, then I really don't want to do it via actually modifying the output on-screen, or else in addition to confusing teachers we're going to break A11Y and copy-paste efforts.

[schanzer]

I can certainly say that the incredibly long decimals or a constant source of consternation for teachers and students alike. I won’t argue with you but their complaints are probably a little silly, but complaints they are and it’s worth thinking about the degree to which we can address them.

A CSS fix is particularly attractive to me because it doesn’t interfere with copy/paste or any of the accessibility stuff, it doesn’t impact any of the complicated value rendering code, and it can be completely ignored by everyone who doesn’t have a problem with it

[blerner]

Ok, so walk through the possible scenarios, and see whether a CSS solution works:

• Suppose you have a massively large integer, ABCDEFGABCDEFGABCDEFG. You impose a maximum width on it, say, 6 digits. Quick -- what's the magnitude of that number? One million and one trillion and one trillion and one googol will look exactly identical, but will all look different than 999999. So a student won't be able to directly read the output of their program and get a meaningful answer.
• Leveling up in difficulty, suppose you have a rational number with massive numerator and denominator. ABCDEFGABCDEFGABCDEFGABCDEFGABCDEFG/tuvwxyztuvwxyztuvwxyztuvwxyz Now you impose a maximum width on it. You'll see ABCDEFGA, with no hint of the denominator, and again no way to deduce its actual magnitude.
• Will clicking on a truncated number reveal its remaining digits? How will that work when clicking on an exact num toggles between fraction and decimal representations -- where will this new click behavior go?
• What about a common fraction like 355/113, whose rational form is 7 characters long, but whose decimal form is 114 characters before repeating. Which bits get truncated in that display, and how do you toggle among the small fraction, the huge decimal, and the truncated decimal?

I don't think this is "just" a CSS fix: you can't just slap on a CSS rule and be done with it, because it interacts with existing number-rendering behaviors, not just their textual forms.

For that matter, why stop with numbers? Why not truncate strings also -- they can be long, too. And at minimum, BS:P teachers frequently complain that when they try to draw a number onto a picture (via text(to-string(the-num))), there are too many digits. So shouldn't to-string of numbers truncate also since "it's too wide"? No, that would be semantically misleading, and so we teach them about num-to-string-digits and all is well again.

[sorawee]

Let's be conservative and only talk about the fractional part (numbers after the decimal point) in a decimal. Just because we don't have a perfect solution for every type of data doesn't mean we can't improve one particular case.

[blerner]

I don't think that helps very much, though. The fractional part of a number isn't meaningful in isolation, because we don't know the magnitude of the overall number. The original complaint in this problem is "wide numbers have lousy appearance", and my counterargument is "visually truncating numbers causes semantic readability problems". Treating the fractional part of a number separately from its integral part isn't meaningful: it doesn't solve the width issue, and it can give misleading information. And it occurs to me that if we have a repeating decimal, then showing the overbar and truncating the output is even more misleading, since it gives a truncated idea of what the fraction should be.

The only syntax for numbers where the digits are equally meaningful is scientific notation, and we know that causes its own bucket of problems, since it's very much unfamiliar to early students.

The more I think about this issue, the less I like it. I'll defer to @schanzer and @shriram about the problematic pedagogical consequences, since they've spent a lot more time with BS:A teachers than I have, but it sure seems to me that they greatly outweigh the benefits of visual brevity.

[sorawee]

I hope that in most calculation, the integral part will be relatively small. It's really the fractional part that is problematic. For example, consider the bouncing ball simulation. The coordinates will always be bound by the window, but it's the fractional part that could be very long.

it can give misleading information

There should be a marker that says the fractional part is truncated. Wouldn't this solve the misleading information problem?

And it occurs to me that if we have a repeating decimal, then showing the overbar and truncating the output is even more misleading, since it gives a truncated idea of what the fraction should be.

This is a good point. I think the option that I proposed should really be about decimal display style. It could be:

1. Not truncated (for roughnum, don't truncate; for rational, show repeating decimal)
2. Truncated for X digits (for roughnum, truncate; for rational, treat repeating decimal as a regular decimal and truncate it).