www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - sfloat24 Floating Point DataType - Request for Comments

reply "Bill Buckels" <bbuckels mts.net> writes:
The sfloat24 data type is half way between a float and a double 
in storage size. It offers high precison and speed, but is 
currently not available as a built-in data type in any compiler 
that I am aware of.

Adding an aditional built-in datatype to a compiler would be alot 
of work, but for some folks sfloat24 may provide an advanatage 
over the cuurently available floating point types currently 
available.

If anyone is interested or wishes to comment on the efficacy or 
feasability of slfloat24, please fell free to weigh-in with your 
thoughts.

Paper One:

http://www.aztecmuseum.ca/sfloat24/PID2445817.pdf

Paper Two:

http://www.aztecmuseum.ca/sfloat24/IPMU_final_version_037.pdf

Additional Links:

https://itunes.apple.com/it/app/dc-motor-simulator-ver.-1.0/id792340664?mt=8

http://en.wikipedia.org/wiki/IEEE_floating_point

D Compiler for .NET — Compiles the code to Common Intermediate 
Language (CIL) bytecode rather than to machine code. The CIL can 
then be run via a Common Language Infrastructure (CLR) virtual 
machine:

http://en.wikipedia.org/wiki/Common_Language_Infrastructure
http://en.wikipedia.org/wiki/Common_Type_System
http://en.wikipedia.org/wiki/Ecma_International

All the best,

Bill
Apr 03 2014
next sibling parent "anonymous" <anonymous example.com> writes:
On Thursday, 3 April 2014 at 20:13:35 UTC, Bill Buckels wrote:
 The sfloat24 data type is half way between a float and a double 
 in storage size.

Wait. 24 bits would be halfway between half (16 bits) and single precision (32 b its).
Apr 03 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/3/14, Bill Buckels <bbuckels mts.net> wrote:
 D Compiler for .NET -- Compiles the code to Common Intermediate
 Language (CIL) bytecode rather than to machine code. The CIL can
 then be run via a Common Language Infrastructure (CLR) virtual
 machine

This seems out of place? What about D for .NET?
Apr 03 2014
prev sibling next sibling parent "Bill Buckels" <bbuckels mts.net> writes:
On Thursday, 3 April 2014 at 20:33:51 UTC, anonymous wrote:
 On Thursday, 3 April 2014 at 20:13:35 UTC, Bill Buckels wrote:
 The sfloat24 data type is half way between a float and a 
 double in storage size.

Wait. 24 bits would be halfway between half (16 bits) and single precision (32 b its).

Could save on byte aligned storage depending on implementation. If stored in 3 bytes. Floats overflow even doing a hue calculation. sfloat24 is very precise. Again depending on implementation, could be faster than doubles. But the precision seems to be the advantage. Give the papers a read. Does anyone do embedded systems or high precision engineering in D? Bill
Apr 03 2014
prev sibling next sibling parent "Bill Buckels" <bbuckels mts.net> writes:
On Thursday, 3 April 2014 at 21:06:52 UTC, Andrej Mitrovic wrote:
 On 4/3/14, Bill Buckels <bbuckels mts.net> wrote:
 D Compiler for .NET -- Compiles the code to Common Intermediate
 Language (CIL) bytecode rather than to machine code. The CIL 
 can
 then be run via a Common Language Infrastructure (CLR) virtual
 machine

This seems out of place? What about D for .NET?

That was really my question:) If D was to have the sfloat24 built-in data type, to what extent would that affect using an interface layer like .NET? Or does anybody use D in .NET? Does anyone care what Microsoft does with their layers? How about IOs? Anything precise happening in D over there? OSX? Would the availability of sfloat24 in D expand the use of D in the .NET environment? Or for that matter any environment? Arduino? Raspberry Pi? Bluetooth? Anyone doing FPGA in D on some new contraption that isn't built yet? Exactly what are your views on sfloat24 after reading the papers? Rsik versus Reward for any language like D in this case that took a giant leap of faith and decided to provide support for sfloat24? Is this just something that electrical engineers are going to use doing experimental programming or has sfloat24 some practical merit that would make it desirable as a built-in data type for the D community. I have none of these answers. I know the group advocating sfloat24 somewhat, and they believe strongly in this data type. I told one of the fellows that I would ask other programmers if they saw a need for sfloat24. Early acceptors like D programmers likely have substantially more vision than complacent old C programmers like me. Double precision has always worked for me in the C language over my last 30 years or so. However I don't do the kind of precision that they do. I also don't program small processors and haven't worried about running out of memory since CP/M, the Apple II and MS-DOS. I haven't worried much about speed in floating point calculations since intel started including a floating point co-processor in their CPU. But it was a real pain, back in the day, to wait for a double precision calculation to complete when we needed to link C with an floating point emulation library for folks who had no co-pros. I could've used a smaller quicker more precise double on those little boxes. The banking software I wrote back then runs after-hours and nobody much cared if it was COBOL or C++ back then... is it still the same job market today for you even in D? Or does the bank just add a couple more blade servers when things bog-down? Do programmers still bury rounding errors in the largest number? With the prevalence of blue-tooth and embedded systems today, are there any D programmers who are working in those environments. Or is most of the world like me, perfectly content to sit on a Windows or a Linux box, and just use the stuff that comes with the compiler. Frankly, the only way I can tell the difference between a program compiled with MinGW, and with Microsoft C, is that the MinGW program is smaller. It doesn't seem faster, and since both map to the same Windows calls, maybe it isn't faster. So does it work the same way in D? When I used the .NET layer for years, I couldn't tell the difference in speed between VB.NET and C#. I couldn't notice any difference in Windows Mobile on a ARM processor either. As far as Linux, whether it wws c or C++, or even the Qt applications I worked on, or even in earlier times using gcc on an IBM360 or whatever when I did 'em all, everything ended-up about the same, so is this more something a compiler might implement independent of any layer at all, and optimize internally based on data type? If so, does anyone want it besides scientists? Where's the use case in D? If any? Questions of that nature... Also is anyone working on a trajectory calculation for a lunar landing in D? My friend Jack Crenshaw is with one of the google ranger groups... but I don't get out much so I don't know what other people do anymore:) So I thought I should ask. Bill
Apr 03 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 03 Apr 2014 16:13:34 -0400, Bill Buckels <bbuckels mts.net> wrot=
e:

 The sfloat24 data type is half way between a float and a double in  =

 storage size. It offers high precison and speed, but is currently not =

 available as a built-in data type in any compiler that I am aware of.

 Adding an aditional built-in datatype to a compiler would be alot of  =

 work, but for some folks sfloat24 may provide an advanatage over the  =

 cuurently available floating point types currently available.

 If anyone is interested or wishes to comment on the efficacy or  =

 feasability of slfloat24, please fell free to weigh-in with your  =

 thoughts.

 Paper One:

 http://www.aztecmuseum.ca/sfloat24/PID2445817.pdf

 Paper Two:

 http://www.aztecmuseum.ca/sfloat24/IPMU_final_version_037.pdf

 Additional Links:

 https://itunes.apple.com/it/app/dc-motor-simulator-ver.-1.0/id79234066=

 http://en.wikipedia.org/wiki/IEEE_floating_point

 D Compiler for .NET =E2=80=94 Compiles the code to Common Intermediate=

 (CIL) bytecode rather than to machine code. The CIL can then be run vi=

 a Common Language Infrastructure (CLR) virtual machine:

 http://en.wikipedia.org/wiki/Common_Language_Infrastructure
 http://en.wikipedia.org/wiki/Common_Type_System
 http://en.wikipedia.org/wiki/Ecma_International

 All the best,

 Bill

I think sfloat24 may only be more performant on 16 bit or low cost = embedded processors. Currently D does not target these. I can't see how an emulated floating 24-bit floating point type could = out-perform a native floating point type. -Steve
Apr 03 2014
prev sibling next sibling parent "Bill Buckels" <bbuckels mts.net> writes:
On Friday, 4 April 2014 at 02:09:11 UTC, Steven Schveighoffer 
wrote:
 I think sfloat24 may only be more performant on 16 bit or low 
 cost embedded processors. Currently D does not target these.

I understand D's current target, and rationale. So where's the advantage? Why would D need sfloat24? Fernando's presence in a meaningful discussion would be interesting on that point.
 I can't see how an emulated floating 24-bit floating point type 
 could out-perform a native floating point type.

Fernando's presence in a meaningful discussion would be interesting on that point as well. On the 386 without a 387 and using a soft floating point link library, the performance degradation was incredible. Going back earlier, running Autocad on an 8086 without an 8087 was impossible. x---x You don't mention precision, so I assume that's not an issue. In general use like banking software, the floating types that we already have are sufficient, and also well understood. Other applications that occasionally use floating point work well. Fernando's presence in a meaningful discussion would be interesting on that point as well. At this point, this thread seems a waste of everyone's time even in a general D language forum. Bill
Apr 04 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/3/2014 1:13 PM, Bill Buckels wrote:
 [...]

As an example of how to efficiently implement a new floating point format as a library type: https://github.com/D-Programming-Language/phobos/pull/1018
Apr 04 2014
prev sibling next sibling parent "Bill Buckels" <bbuckels mts.net> writes:
On Friday, 4 April 2014 at 18:05:50 UTC, Walter Bright wrote:
 As an example of how to efficiently implement a new floating 
 point format as a library type:

 https://github.com/D-Programming-Language/phobos/pull/1018

Thanks Walter... Fernando and Riccardo (Grecco) are sure to have seen this by now. It was Ric who forwarded me the link. This starts to give us more to chew-on. Bill
Apr 04 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
Wow many questions. I'll try my best but I'm not the most 
knowledgeable person out there.

On Friday, 4 April 2014 at 01:20:43 UTC, Bill Buckels wrote:
 On Thursday, 3 April 2014 at 21:06:52 UTC, Andrej Mitrovic 
 wrote:
 
 This seems out of place? What about D for .NET?

That was really my question:) If D was to have the sfloat24 built-in data type, to what extent would that affect using an interface layer like .NET?

 Or does anybody use D in .NET? Does anyone care what Microsoft 
 does with their layers?

and dynamic arrays was one of the problems IIRC. So no, I think nobody runs D on the CLR.
 How about IOs? Anything precise happening in D over there? OSX?

 Would the availability of sfloat24 in D expand the use of D in 
 the .NET environment? Or for that matter any environment? 
 Arduino? Raspberry Pi? Bluetooth?

No since D already have custom float, which can be tailored for the problem at hand (like you would tailor a fixed-point integer to a particular problem).
 Anyone doing FPGA in D on some new contraption that isn't built 
 yet?

converted to FPGA code.
 Exactly what are your views on sfloat24 after reading the 
 papers? Rsik versus Reward for any language like D in this case 
 that took a giant leap of faith and decided to provide support 
 for sfloat24?

I personally don't need that type. I would say risk = reward = 0 :), since custom numerical data-type can be easily implemented in D. Might be useful on small hardware with no accelerated float like you suggested.
 Is this just something that electrical engineers are going to 
 use doing experimental programming or has sfloat24 some 
 practical merit that would make it desirable as a built-in data 
 type for the D community.

Well it doesn't need to be builtin anyway, so you can go ahead and implement sfloat24.d
 The banking software I wrote back then runs after-hours and 
 nobody much cared if it was COBOL or C++ back then... is it 
 still the same job market today for you even in D? Or does the 
 bank just add a couple more blade servers when things bog-down?

and you can't just tell the customer to add blades, consumption and space are important too.
 With the prevalence of blue-tooth and embedded systems today, 
 are there any D programmers who are working in those 
 environments.

There are a few.
 If so, does anyone want it besides scientists? Where's the use 
 case in D? If any?

Very high code reuse through classical OO polymorphism and static polymorphism. High performance, productivity and friendliness. Doing any calculation at compile-time, then generating code out of it. Not dealing with the high cost of writing C++ ;) A lot of liberty in the way of doing things.
 Questions of that nature...

 Also is anyone working on a trajectory calculation for a lunar 
 landing in D? My friend Jack Crenshaw is with one of the google 
 ranger groups... but I don't get out much so I don't know what 
 other people do anymore:)

 So I thought I should ask.

 Bill

Apr 05 2014
prev sibling parent "Fernando " <f.parillo alice.it> writes:
I am Eng. (Electrical Engineer) Fernando Parillo of University of 
Cassino, Italy, author of several papers about sfloat24 math 
library. I conceived this library, in the early of 2007 and this 
library worked in stable manner in the middle of 2010, date of 
publication of the first paper concerning its usage on a FPGA 
device concerning the implementation of a control strategy 
applied to a Power Electronic converter, July 2010. As well known 
a FPGA is a programmable digital logic device by software. Thus, 
it can execute any logical function such as numeric processors, 
digital interface, controllers and decoders only in a single IC. 
The FPGA architecture contains programmable logic components 
called Configurable Logic Blocks (CLB), and a hierarchy of 
reconfigurable interconnects that allow the blocks to be wired 
together. The CLB can be configured to make complex combinational 
functions, or only simple logic gates like AND and XOR.
In most FPGA, the CLB also include memory elements, which can be 
simple flip-flops or more complete blocks of memory. FPGAs are 
programmed using a logic circuit diagram or a source code in 
Hardware Description Language (HDL). The main motivation to 
develop this library was to implement a floating-point numerical 
system on a low cost FPGA device, as an ALTERA Cyclone I. It is 
obvious that this library could be suitable also for low cost 
microcontrollers where the ALU has low performances. In view of 
the circumstances of the new programming language, development, 
as D language, could be useful to include a short floating-point 
number format in it, as native numbering system. A reduced 
floating-point library could be very useful for low cost 
processors programming. Nowadays low cost microcontrollers and/or 
microprocessors offer acceptable performances only if integer 
numbers are used. If you are interested to implement this format 
in the future D programming language, I could offer my support. 
For me this collaboration could be an excellent 
experience/opportunity to improve the sfloat24 math library and 
the same time to learn more about computer science skills. At 
moment I have implemented, the basic arithmetic operations, 
square root of a number, hyperbolic/trigonometric functions, etc. 
  To understand the utility of this floating-point format you 
could look for “sfloat24 converter tool ver. 1.1” available on 
the Apple® app. Store. For any questions do not hesitate to 
contact me by email o directly using SKYPE.

Best Regards
F. Parillo

University of Cassino Research Assistant, Apple® IOS developer
Website:  http://fparillo.wix.com/accademic , SKYPE account: 
f.parillo

Thanks a lot for your paid attention and have a nice day.
Apr 15 2014