Actually, I inferred probably the wrong reason we use C* rather than
(void*) for the contents of arrays in J.
The "real reason" is probably that pointer arithmetic is illegal for
void*, but pointer arithmetic works right for char*
(I use C* and char* interchangeably here, because of that definition
in jtype.h).
Anyways, I'm not always right and I wanted people to be aware that
there's a better reason than the one I suggested.
Thanks,
--
Raul
On Sun, Jun 12, 2016 at 8:05 AM, Raul Miller <rauldmil...@gmail.com> wrote:
> I agree with bill lam.
>
> And why this is might be worth going over for people not comfortable
> reading J's source code.
>
> Here's the code being modified:
>
> static void jtfmt1(J jt,B e,I m,I d,C*s,I t,C*wv){D y;
> switch(t){
> case B01: sprintf(jt->th2buf,s,(D)*wv); break;
> case INT: sprintf(jt->th2buf,s,(D)*(I*)wv); break;
> case XNUM: fmtx(e,m,d,s,t,(X*)wv); break;
> case RAT: fmtq(e,m,d,s,t,(Q*)wv); break;
> default:
> y=*(D*)wv; y=y?y:0.0; /* -0 to 0 */
> if (!memcmp(wv,&inf, SZD))strcpy(jt->th2buf,e?" _" :' '==*s?" _" :"_"
> );
> else if(!memcmp(wv,&infm,SZD))strcpy(jt->th2buf,e?" __" :' '==*s?"
> __":"__");
> else if(_isnan((float) *wv) )strcpy(jt->th2buf,e?" _.":' '==*s?"
> _.":"_.");
> else sprintf(jt->th2buf,s,y);
> }} /* format one number */
>
> And the change changes:
> else if(_isnan(*wv) )strcpy(jt->th2buf,e?" _.":' '==*s?" _.":"_.");
>
> to
> else if(_isnan((float) *wv) )strcpy(jt->th2buf,e?" _.":' '==*s?"
> _.":"_.");
>
>
>
> But
> (1) J uses the (double) data type rather than the (float) data type.
> https://github.com/jsoftware/jsource/blob/master/jsrc/jtype.h#L37
>
> (2) the (wv) variable type is a pointer to character (because the code
> was written based on documentation which was written before pointer to
> void became popular for handling this kind of issue).
> https://github.com/paspanag/jsource/blob/b4c69a3887a7586a3282cdbdbad34f0fa84aef68/jsrc/f2.c#L132
>
> And, in fact, if you look at line 139, you see the *(D*)wv pattern
> being used to first transform the wv pointer into a pointer to a
> double and then to find the value being pointed at.
>
> That said, line 139 looks like this:
> y=*(D*)wv; y=y?y:0.0; /* -0 to 0 */
>
> and so it's tempting to think that maybe we should just use (y)
> instead of spelling out (*(D*)wv) again.
>
> But there's also the worry about y having been reassigned.
> Conceptually speaking, a NaN value is not a negative zero value or any
> kind of zero value. But people like to argue all the time, and NaN
> values are mathematical nonsense so you never know what is valid about
> them. See, for example:
> http://stackoverflow.com/questions/9158567/nan-to-bool-conversion-true-or-false
>
> There, some people reason that NaN values are true values while others
> quite rightly retort that NaN values are not true values.
>
> Anyways, you never know what changes people will be trying to make and
> for something nonsensical like NaN it pays to be a little cautious.
>
> So, anyways, the patch here would get a character value from the
> "first" byte of the number being tested and then transform that to a
> float value before testing whether the value was an IEEE 754 floating
> point representation of a "Not a Number" value. And since characters
> are never NaN values (they are instead values in the range -128 ..
> 127) I think this change would have made it so that we would not see
> _. when formatting numbers.
>
> (But I have not actually tested code with that change, to know exactly
> what would have happened when trying to format a NaN value. J mostly
> prevents those values from existing in the first place, because they
> are nonsense, but there are a few ways to get them to exist.)
>
> Anyways, I saw this and I thought that maybe I should go through the
> kind of thinking you might infer from what bill was suggesting.
>
> Thanks,
>
> --
> Raul
>
>
>
> On Sun, Jun 12, 2016 at 6:46 AM, bill lam <bbill....@gmail.com> wrote:
>> I think the proper fix should be
>> *(D*)wv
>> ---------- Forwarded message ----------
>> From: "Peter Panaguiton" <notificati...@github.com>
>> Date: Jun 10, 2016 4:38 AM
>> Subject: [jsoftware/jsource] gcc complaining about type for _isnan. (#1)
>> To: "jsoftware/jsource" <jsou...@noreply.github.com>
>> Cc:
>>
>> Trying to packge the j git version as the current version in the Nixos
>>> packages is broken. Built it with this as the only error stopping it from
>>> being built with Nixos's current gcc (gcc 5.3 and glibc 2.23).
>>> ------------------------------
>>> You can view, comment on, or merge this pull request online at:
>>>
>>> https://github.com/jsoftware/jsource/pull/1
>>> Commit Summary
>>>
>>> - gcc complaining about type for _isnan.
>>>
>>> File Changes
>>>
>>> - *M* jsrc/f2.c
>>> <https://github.com/jsoftware/jsource/pull/1/files#diff-0> (2)
>>>
>>> Patch Links:
>>>
>>> - https://github.com/jsoftware/jsource/pull/1.patch
>>> - https://github.com/jsoftware/jsource/pull/1.diff
>>>
>>> —
>>> You are receiving this because you are subscribed to this thread.
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/jsoftware/jsource/pull/1>, or mute the thread
>>> <https://github.com/notifications/unsubscribe/ABg1YZJ46q9zqI5yvmNYjfcv-3n59I36ks5qKHmtgaJpZM4IyYR7>
>>> .
>>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
