I didn't mean to come across as a floating point purist. It points to a
disparity in how ghwdump prints and how gtkwave sprintfs the value for display.
As I understand it the gtkwave user can also do realtobits if they are doing
gate level modeling. If someone is doing textual comparison they can filter
precision and crossing over to/from IEEE 754 is their own concern.
Any idea why I'm not seeing your fix for s2r, s3r, s4r and s5r? (#38, #39, #40
and #41)
All they display is zeros, when ghwdump appears to show non-zero values.
On May 5, 2012, at 10:12 AM, <byb...@nc.rr.com> <byb...@nc.rr.com> wrote:
> David,
>
> ghwlib uses %g. I use %.16g for my format. I have no idea what a user wants
> so I print full precision. From a usability point-of-view I can see how this
> is annoying.
>
> Given how nice power of ten fractions often have no accurate representation
> in IEEE, that's what you're seeing.
>
> I should probably add an option for users to specify how many significant
> digits should be. (i.e., the formatting argument) The fix would be easy and
> would be localized here:
>
> baseconvert.c: sprintf(os, "%.16g", d);
> baseconvert.c: sprintf(rv,"%.16g",*d);
> baseconvert.c: sprintf(os, "%.16g", d);
>
> -Tony
>
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> double d = 8.561499999999999;
> double e = 8.5615;
>
> printf("%g\n", d);
> printf("%.16g\n", d);
>
> printf("%g\n", e);
> printf("%.16g\n", e);
>
> return(0);
> }
>
>
> 74:/tmp> ./t
> 8.5615
> 8.561499999999999
> 8.5615
> 8.561500000000001
>
>
>
>
> ---- David Koontz <diogra...@gmail.com> wrote:
>> On May 5, 2012, at 4:43 AM, <byb...@nc.rr.com> <byb...@nc.rr.com> wrote:
>>
>>> Fixed in SVN revision 620. Thanks for reporting this.
>>>
>>> I've also just uploaded a fixed OSX gtkwave.zip app bundle (candidate for
>>> 3.3.36) onto the main page at the gtkwave.sourceforge.net website.
>>>
>>> -Tony
>>
>>
>> Thanks Tony.
>>
>> The gtkwave.zip shows as updated:
>> Contents/ May/03/12 6:40 PM
>> Contents/MacOS/gtkwave-bin May/03/12 6:40 PM
>>
>> The waveform still appears incorrect.
>>
>> s6r (#42) shows correctly except for the trailing 99999.. in the fraction
>> part, #38, #39, #40, #41 display 0 instead of 2 at 2). Seems a problem s6r
>> too or ghwdump may be truncating #42 removing the trailing 99999..
>>
>> This is with the same .ghw waveform file I generated yesterday. I updated
>> the save file to fit to your screen size and set the cursor close to the
>> following extracted by ghwdump.
>>
>>>> /Applications/gtkwave.app/Contents/Resources/bin/ghwdump -shtv *.ghw >
>>>> ghw_dump
>> (yesterday, I'm GMT-12)
>>
>> ...
>> signal s2: integer #34
>> signal s3: positive #35
>> signal s4: natural #36
>> signal s5: <anon> #37
>> signal s2r: real #38
>> signal s3r: real #39
>> signal s4r: real #40
>> signal s5r: real #41
>> signal s6r: real #42
>> ...
>> Time is 30000000 fs
>> #1: '1' (3)
>> #2: '0' (2)
>> #3: '0' (2)
>> #4: '0' (2)
>> #5: '0' (2)
>> #6: '0' (2)
>> #7: '0' (2)
>> #8: '0' (2)
>> #9: '0' (2)
>> #10: '0' (2)
>> #11: '0' (2)
>> #12: '0' (2)
>> #13: '0' (2)
>> #14: '0' (2)
>> #15: '0' (2)
>> #16: '1' (3)
>> #17: '0' (2)
>> #18: '0' (2)
>> #19: '0' (2)
>> #20: '0' (2)
>> #21: '0' (2)
>> #22: '0' (2)
>> #23: '0' (2)
>> #24: '0' (2)
>> #25: '0' (2)
>> #26: '0' (2)
>> #27: '0' (2)
>> #28: '0' (2)
>> #29: '0' (2)
>> #30: '0' (2)
>> #31: '0' (2)
>> #32: '1' (3)
>> #33: '0' (2)
>> #34: 2
>> #35: 2
>> #36: 2
>> #37: 2
>> #38: 2
>> #39: 2
>> #40: 2
>> #41: 2
>> #42: 8.5615
>> ...
>>
>
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
