Decimal point as a binary operation [closed]

Question

I wonder if anyone has tried implementing the decimal point as a binary operation a.b = $f(a, b) = a+b/10^{1+floor(log_{10} b)}$

That would simplify the PL design, and add new possibilities. For example, (-2).34 is equal to -1.66,
3.(1+6*5) is 3.31

Answer 1

Sort of. In Fortress, a decimal point (or I would rather call it an "integer and real part separator", because Fortress allows number literals in bases other than base-10) is syntactical sugar for a fraction. That is the closest example I can think of (which I freely admit is still pretty far away from what you are asking).

I.e.,

1.234

is syntactical sugar for

1234/1000

and

1.234_16

is syntactical sugar for

1234_16/1000_16

which is equal to

4660/4096

Fortress does not support so-called "scientific notation", instead you would just write something like:

1.234_16 * 10_8^11_2

which is syntactical sugar for

1234_16/1000_16 * 10_8^11_2

and equivalent to

4660/4096 * 8^3

which will be compile-time evaluated to

1165/2

Note that Fortress has three different syntaxes:

• Fortress syntax
• Unicode syntax
• ASCII syntax

The canonical syntax is Fortress syntax, and both ASCII syntax and Unicode syntax are used for editing and file storage, but source code is generally rendered in Fortress syntax. This code in the ASCII syntax:

1234_16/1000_16 * 10_8^11_2

Would be rendered roughly like this in the Fortress syntax:

This is the closest example I know of. This is not treating the decimal point as a binary operator, but it is translating literals containing a decimal point into an expression containing a binary operator.

Fortress was specifically designed for High-Productivity Computing, which is a slightly different take on "HPC" (High-Performance Computing). Traditional HPC optimizes for "fastest time from pushing the button to the result", whereas High-Productivity Computing optimizes for "fastest time from formulating the problem to the result", in other words, this interpretation of HPC takes into account the time it takes to write the program in the first place.

As a result, two of Fortress's main principles were:

• Make it as easy as possible to translate a problem specification (which is typically written in mathematical language, not pseudo-code) into a program.
• Make it as easy as possible to write highly-performant, highly-parallel, highly-distributed programs that perform well on a heterogeneous super-computing cluster.

Hence, the almost LaTeX looking syntax and the very high level of abstraction, but also the attention to detail when it comes to specifically numbers, number literals, and algebra.

Answer 2

(In this answer, I will use the code notation for your language (1.5) and LaTeX for the resulting value it is evaluated to ($1.5$).)

So, as mentioned in the comments by RubenVerg: 2.01 should be $2.01$, not $2.1$. Using 01 == 0.1 will not work: using that convention we still have $f(2, 0.1) = 2.1$.

In fact, let's say we want to find a $b$ such that $f(2, b) = 2.01$.

Then we have $b/10^{1+\lfloor \log_{10} b \rfloor}=0.01$. That simplifies to $b=10^{\lfloor \log_{10} b \rfloor -1} $, and taking the logarithm of both sides we get $\log_{10} b= \lfloor \log_{10} b \rfloor -1 $, and I hope you'll agree that we can't find such a $b$. In fact, no such $b$ exists for any $f(0, b) < 0.1$.

There are two solutions I can see that gives us a binary operation are:

1. Remember the preceding zeroes for integers. For example, 001 != 1*. Then we could have $f(a, b, c) = a + 10^{-c}b$, where $b$ is the numerical value of the fractional part, and $c$ is the number of digits of the fractional part, including leading zeroes.

   $c$ has to be a property of the value, which is weird, you now have these extra integers hanging around that serve no purpose other than for passing to the right hand side of the . operator.

2. Have an infinite family of operators: ., .0, .00, ... In that case, 0.(y) could never be smaller than $0.1$.

Either way, I don't think it's worth the additional complexity.

* You'll probably want that property, otherwise it's possible to have y1 == y2 && 1.(y1) != 1.(y2).