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

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).

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?

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

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

On Thu, 03 Apr 2014 16:13:34 -0400, Bill Buckels <bbuckels@mts.net> wrote:

> 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

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

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

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

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

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?
Wouldn't affect.

> Or does anybody use D in .NET? Does anyone care what Microsoft does with their layers?
There was D.NET attempt but it has stalled, conflation of slices 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?
D runs native there.

> 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?
Don't think so. FPGA men mostly have contempt for C code 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?
I don't work in this field but performance is still paramount, 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