About varocarbas.com

--

About me

--

Contact me

--

Visit customsolvers.com, another side of my work

--

Valid markup

--

Valid CSS

--

© 2015-2017 Alvaro Carballo Garcia

--

URL friendly

--

Optimised for 1920x1080 - Proudly mobile unfriendly

R&D projects RSS feed

All projects in full-screen mode

PDFs:

Project 10

Project 9

Project 8

FlexibleParser code analysis:

UnitParser

NumberParser

Tools:

Chromatic encryption

(v. 1.3)

Pages in customsolvers.com:

Upcoming additions

Failed projects

Active crawling bots:

Ranking type 2

(
)

Currently active or soon to be updated:

Domain ranking

FlexibleParser (DateParser)

NO NEW PROJECTS:
Project 10 is expected to be the last formal project of varocarbas.com. I will continue using this site as my main self-promotional R&D-focused online resource, but by relying on other more adequate formats like domain ranking.
Note that the last versions of all the successfully completed projects (5 to 10) will always be available.
PROJECT 10
Completed (24 days)

Introduction >

.NET decimal type

Completed (57 days)
Completed (26 days)
Completed (47 days)
Completed (19 days)
Completed (14 days)
Non-floating-point fractional exponentiation approach
Completed on 16-Nov-2016 (24 days)

Project 10 in full-screenProject 10 in PDF

As per the corresponding MSDN reference for C#, decimal is a 128-bit data type whose precision (e.g., 0.0000000000000000000000000001m) and range (e.g., 7e28m) are around 28 digits. Contrarily to what happens with the other .NET decimal types (i.e., double and float), it isn't floating point.

The decimal type is defined by its high precision and that's why this has been an accuracy-oriented development since the very beginning. As explained in the corresponding section, the immediate result of such an intention is that PowDecimal/SqrtDecimal take into account most of the significant digits of the decimal type (note that the reasons for only "most of", the first 25 decimal digits, are also explained in the aforementioned other section).

The relatively big decimal range is also an important issue for the integer exponentiation aspects of this implementation. Note that this range is notably beyond the one of the biggest signed integer type (i.e., long, around ±9.2*10^18) and, consequently, no integer type might be used. The main consequence of such a limitation is the impossibility of relying on bitwise operations.