Changing the "~" units operator

[Ted Kosan]

In preparation for teaching ETEM1110 "Electrical Fundamentals (DC)" in
the fall, I have been creating automatically graded worksheets for the
DC section of the textbook that is used in this class. Problem 6.9
requires a series equivalent circuit to be derived from a series
parallel circuit. This kind of problem is more challenging to
automatically grade than problems that require values to be returned
are.

Last semester I started working on an algebraic circuit notation that
can be used for representing series-parallel circuits ("~~" means
"series" and "||" means "parallel"):

'(9~V ~~ (2.2~kΩ ~~ 3~kΩ || 1.2~kΩ ~~ 300~Ω) ~~ 1~kΩ ~~ 1.5~kΩ)

Unfortunately, the "~" units operator and the "~~" series operator are
too similar to enable easy visual parsing of an expression that
contains both of them. Using "~~" to indicate "series" and "||" to
indicate "parallel" has worked well so far. Alex, who is visually
impaired, says he often confuses "~" with the "-" operator when
working with units. Therefore, I think replacing the "~" operator
should be explored first.

Alex suggested using "`" as the units operator:

'(9`V ~~ (2.2`kΩ ~~ 3`kΩ || 1.2`kΩ ~~ 300`Ω) ~~ 1`kΩ ~~ 1.5`kΩ)

I find this expression to be easier to visually parse than the
previous one. Alex said it is significantly easier for him to visually
parse "`" than "~" is. It is also easier to type.

Of course, the "`" operator is already being used for Lisp-style
backquoting, so another operator or a procedure name would need to be
found for it (and also for "``" to preserve uniformity). However,
since these backquoting operators will not be used nearly as heavily
as the units operator will, I think priority should be given to the
units system.

Can anyone think of a better operator to replace "~" with than "`" ?

Ted

[Kyle Johnson]

It may be less convenient or it may come off as bit loud but it looks like the "@" operator isn't in use currently. I think it can easily be seen in comparison to the "`". 

I am a bigger fan of the larger symbols as it makes it easier to see during class regardless of where you are seated in the room.

[Nick]

I personally don't like the idea of using the backquote character, but
I'm used to it from lisp. If you go forward and switch "~" to "`" you
could rename the current backquote procedures to quasiquote and
quasiquote2. I have no other suggestion on what would be character to
use.

Not to derail, but am I correct in remembering that "`" allows
unquoted forms and "``" allows splicing unquote? I feel like I
remember thinking that it was odd that "`" didn't implement both.

> --
> You received this message because you are subscribed to the Google Groups
> "mathpiper-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mathpiper-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mathpiper-dev/955933e4-40bf-42a4-a1d9-1e6a99ac2e58%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


--
Nick

[Ted Kosan]

I think this issue is a good candidate for using a decision procedure
on. The decision procedure I have the most experience with is PrOACT:

https://www.project-management-skills.com/decision-making-model.html

I will do a PrOACT analysis over the next few days and then report the results.

Ted

> To view this discussion on the web visit https://groups.google.com/d/msgid/mathpiper-dev/CAFU-7WCx0PNMdM3hO%2BAzTjOPq1xucT2M%3Djt5mDAF8Zf6Qgnnmw%40mail.gmail.com.

[Ted Kosan]

These are the objectives I came up with for this decision problem.

Find an operator that:
- Does not clash with the ~~ operator.
- Is easy to visually parse on a projector screen.
- Matches the "loudness" of the operation.
- Has minimal impact on the set of existing Lisp-related operators.

"Loudness" here is defined by how much the operator stands out in an
expression. Here are all of the currently defined operators ordered
from high to low precedence (I created a new procedure named
"OperatorsGet" to obtain this information"):

In> (MapSingle("ToAtom", OperatorsGet()))
Result: [',@,`,:*:,~,++,--,:,<<,>>,∠,^,+,-,.,/,X,bin,hex,o,*,***,+,-,~~,||,!==,!=?,<=>,<=?,<>,<?,==,=?,>=?,>?,@@,!?,..,/@,&?,|?,AddTo,#,->?,==?,Where,'',::,``,##,-->,->,/:,/::,+:=,-:=,:=,Else]

In an expression tree, operators that are higher in the tree have more
of an impact on the expression's structure than operators lower in the
tree do. Therefore, operators that are higher in an expression tree
should stand out more than operators that are lower in the tree. As an
example, notice that the very low precedence operators &? and |? have
their backgrounds syntax highlighted so they stick out much more than
higher precedence operators do.

The units operator is a very high precedence operator. Therefore, it
should be a "quiet" operator that does not stand out very much. In
fact, in science textbooks, juxtaposition is used between a value's
numeric part and its unit part to indicate the presence of an implicit
units operator.

In light of this information, I have decided to change the "~"
operator to "`" and test it during fall semester to see how well it
works. As for loosing the "`" operator as a Lisp-like quasiquote
operator, this is indeed a sacrifice. However, if "`" works out well
as a units operator, I think the sacrifice is worth it because in
theory many more users will be using units than will be using
quasiquoting.

I like the idea of using "Quasiquote" and "Quasiquote2" as
replacements for the existing "`" and "``" operators. It would then
probably make sense to rename the "Hold" procedure to "Quote" to be
compatible with this change. Eventually, it would make sense to move
Quasiquote2's splicing capability into Quasiquote. The reason it is
not there already is splicing capability was created under a very
tight timeline near the beginning of spring semester, and there was
not time to properly integrate it into the existing "`" operator.
Technical debt is easy to create and difficult to pay off...

Ted

[Nick]

Sounds reasonable. I'm quite confident that no one in one of your
classes has used quasiquoting as it was anyway. Needs of the many over
the needs of the few and all that.

In thinking about it more: since the change in question is from a
prefix operator to an infix one there shouldn't be any room for
confusion from a lisp standpoint.

The only sacrifice is not having the reader macro (or equivalent term
- I don't remember how they're implemented) available for use in the
core library. Depending on how much will need to be reworked it might
be advantageous to attach quasiquote to another character. This would
most definitely look weird at first, but could cut down on the work
required significantly.

> https://groups.google.com/d/msgid/mathpiper-dev/CAOJRwx2-45H_8-NHBAKTomNUTyZPYJ7T5a6OWJ1CwztoS%3D2DTQ%40mail.gmail.com.
>


--
Nick

[Ted Kosan]

The old "~" units operator has been changed to "`" as of revision
2201d975. I have been using the new "`" units operator for the past
few days, and so far I like it.

Instead of using "quasiquote" as a replacement for "`", I went with
Nick's suggestion to combine "`" with another character. The old "`"
was changed to "/`" (and "``" was changed to "/``). I picked these
combinations to suggest a similarity with the "/." and "/.." local
rules operators.

Ted

> To view this discussion on the web visit https://groups.google.com/d/msgid/mathpiper-dev/CAFU-7WDUSGEkXM2dJmN-s8DkSc9J_%2BkmAQ5qjA6zK7OewPt9GQ%40mail.gmail.com.