On Thursday, 28 June 2012 at 16:50:59 UTC, David Nadlinger wrote:
> On Thursday, 28 June 2012 at 14:35:24 UTC, Andrei Alexandrescu wrote:
>> On 6/28/12 10:07 AM, Roman D. Boiko wrote:
>>> On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
>>>> I think just exposing them via .sig and .exp might be the way to go?
>>>
>>> sig is easy to confuse with sign
>>
>> .mantissa and .exp
>
> .exp might potentially lead to confusion regarding std.math.exp with UFCS in place. Not that this would be a huge deal, but since new property would be used only very rarely anyway, I don't think going for a longer name like .exponent or even rawExponent/exponentBits/… would be a problem.
>
> David

In my BigDecimal/BigFloat modules I use .coefficient and .exponent externally but .mant and .expo internally. It would be nice to be consistent -- I can adapt to whatever is best.

Paul

On Thursday, 28 June 2012 at 16:50:59 UTC, David Nadlinger wrote:
> On Thursday, 28 June 2012 at 14:35:24 UTC, Andrei Alexandrescu wrote:
>> On 6/28/12 10:07 AM, Roman D. Boiko wrote:
>>> On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
>>>> I think just exposing them via .sig and .exp might be the way to go?
>>>
>>> sig is easy to confuse with sign
>>
>> .mantissa and .exp
>
> .exp might potentially lead to confusion regarding std.math.exp with UFCS in place. Not that this would be a huge deal, but since new property would be used only very rarely anyway, I don't think going for a longer name like .exponent or even rawExponent/exponentBits/… would be a problem.
>
> David

How about .mant and .expo?

That's what I'm using in the BigDecimal/BigFloat modules as private names. The property names are .coefficient and .exponent.

On 28/06/12 18:37, David Nadlinger wrote:
> On Thursday, 28 June 2012 at 15:28:10 UTC, Don Clugston wrote:
>> There's an oddity, though: the type of X.significand would be
>> dependent on the type of X […]
>
> I don't think this is a problem at all – for example, the type of T.init
> depends on T as well…
>
> David

Good point.

On 28/06/12 18:36, Jens Mueller wrote:
> Don Clugston wrote:
>> On 28/06/12 17:00, Jens Mueller wrote:
>>> Andrei Alexandrescu wrote:
>>>> On 6/28/12 10:07 AM, Roman D. Boiko wrote:
>>>>> On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
>>>>>> I think just exposing them via .sig and .exp might be the way to go?
>>>>>
>>>>> sig is easy to confuse with sign
>>>>
>>>> .mantissa and .exp
>>>
>>> Letting the compiler define these properties is a solution. I thought
>>> Don is looking for something more general. But maybe this isn't needed
>>> here. Don't know. But using mantissa should be discouraged.
>>> I suggest calling them
>>> .significand and .exponent
>>>
>>> significand is preferred over mantissa by IEEE FP committee. I think
>>> it's fine to spell them out. There won't be much code using them anyway.
>>>
>>> Jens
>>
>>
>> Yes, adding new properties would be the easiest way from a CTFE
>> perspective; that way, they are endian-ness independent. It's a bit
>> niche, but then again adding a special case for this in CTFE is
>> niche as well. Maybe it would be the best approach.
>
> Sounds good then.
>
>> With naming, I'm included to agree, but the funny thing is that we
>> have X.mant_dig as the number of digits in the significand.
>
> You could add a deprecated alias to X.mant_dig and provide a new name.
> We should adopt IEEE's vocabulary where possible.
>
>> There's an oddity, though: the type of X.significand would be
>> dependent on the type of X (and for the non-existent quadruple
>> float, it would be non-existent ucent type!)
>
> But this is no problem, is it?
>
>> Would it include the implicit bit of an 80-bit x87 real (the silly bit)?
>
> Not sure what the silly bit is. You mean the bit that is implicitly
> always 1, don't you? mant_dig says 24 for a float. Means it is included
> when counting the bits. Then for consistency it should be included.

Yes, the implicit bit. For float and double it isn't present, but it's there for 80bit x87 and 68K reals.
But it would not be present for quadruple types. I'm not sure if it's always present on Itanium 80-bit reals.

It's included in the 80-bit reals only for historical reasons -- it seemed like a good idea at the time. It allowed an optimisation for a long-obsolete algorithm.

On Thursday, 21 June 2012 at 16:39:07 UTC, Alex wrote:
> is it possible to use D to write code to work without OS?
> like i do it with gcc.

by the way, with which args i must run D to generate raw binary?

On Tuesday, 11 February 2014 at 11:53:48 UTC, AlexPhoenix wrote:
> by the way, with which args i must run D to generate raw binary?

This is more of a linker question than a compiler one...

check out the makefile.bare in here
http://arsdnet.net/dcode/minimal.zip

It makes a raw binary that can be loaded by GRUB

On Tuesday, 11 February 2014 at 18:09:56 UTC, Adam D. Ruppe wrote:
> On Tuesday, 11 February 2014 at 11:53:48 UTC, AlexPhoenix wrote:
>> by the way, with which args i must run D to generate raw binary?
>
> This is more of a linker question than a compiler one...
>
> check out the makefile.bare in here
> http://arsdnet.net/dcode/minimal.zip
>
> It makes a raw binary that can be loaded by GRUB

I found trouble.
I trying to do the same
with: dmd -m32 -debug -c ITextScreen.d -gc -defaultlib= -debuglib= -version=bare_metal -debug=allocations
and the then i trying to link with ld(also try with objcopy and gcc) from MinGW, and have
ITextScreen.obj: file not recognized: File format not recognized

what i do wrong?

On 6/22/2012 11:21 AM, Mehrdad wrote:
> On Friday, 22 June 2012 at 15:12:13 UTC, Timon Gehr wrote:
>
> Isn't the quote
>> If you can't figure it out on your own, chances are you won't be able to
> do what you wanted in the first place
> just saying I'm too stupid for this to help me anyway?

No, that quote is merely pointing out, for cautionary purposes, that the task you're ultimately trying to do is typically either equally difficult, or more difficult, than this first step you're currently on. If I'm reading correctly, he simply doesn't want you to end up being unpleasantly surprised by what you may face once you do reach that point.

But explaining it that way is verbose and difficult (I spent entirely too long figuring out how to word it - and I'm a native speaker), so he wrote it in a more straightforward way: As an "A implies B" relation, ie an rather frank and blunt "if...then".

(AIUI, anyway)

Slight soapbox, not directed at anyone in particular:

Emotion tends to severely complicate communication, so for technical things (which tend to *already* be difficult to communicate), a person speaking/writing will frequently need to disregard emotion-related concerns in their choice of wording. Therefore, when reading/listening, it's best to "Be like Spock, not Bones" and always assume anything that *can* be interpreted unemotionally or benign was *intended* to be unemotional and benign, regardless of whether or not that might be a false assumption.

Granted, as a reader/listener, there have been plenty of times I've colossally failed to follow that guideline, so I'm certainly not immune from such failings myself. But it's a working theory I've formulated after being in (and near) a few too many flamewars, and FWIW I think it's fairly sound.