Re: [fpc-pascal] H2pas tool vs others, C header translation
In our previous episode, Dmitry Boyarintsev said: > > I'm using Chelper. (http://wiki.freepascal.org/Chelper) > It's my choice, because it preserves comments (which is usually an > important part of open-source libs) > plus, can be configured to handle library header-specific defines. > Naturally, the process is semi-automatic, but get be done quite quickly. Note that to convert C (as in source code, not headers), I did use other tools in the past. Can't remember which though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] H2pas tool vs others, C header translation
On 2017-08-21 13:08, mar...@stack.nl wrote: In our previous episode, Michael Van Canneyt said: > I am looking to convert the GNU MPFR library header files, or hire > someone on a bounty to do it if header translation is not so easy with > h2pas and requires lots of hand work, and close checking. I do all header translations with h2pas. Most of the time, I run the code first through gcc -E, which will take care of all macro magic. Usually h2pas has little trouble with the result. Before everything I do a couple of substs with an editor, What do you mean by substs.. Search/replace, (substitutions? regex?) gcc -E I use small pascal filterprograms to sort the symbols based on heuristics. Usually "clean" defines, structs, function calls and "rest". A custom filter program for each case by case basis, or one major filter program you wrote for all header files? Thanks for the tips. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] H2pas tool vs others, C header translation
On 2017-08-22 04:04, mar...@stack.nl wrote: In our previous episode, Dmitry Boyarintsev said: I'm using Chelper. (http://wiki.freepascal.org/Chelper) It's my choice, because it preserves comments (which is usually an important part of open-source libs) plus, can be configured to handle library header-specific defines. Naturally, the process is semi-automatic, but get be done quite quickly. Note that to convert C (as in source code, not headers), I did use other tools in the past. Can't remember which though. I did mean headers, not C source... But C source is also interesting to convert of course I wonder if the Quake to Delphi and Doom To Delphi folks wrote tools for conversion, or used existing ones to do the bulk of the work. If superman was involved, they likely did it by hand 100 percent the hard way, but if they are A.I. then they have no hands, likely. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freepascal Floating Point Issue
Hi James, Its unlikely that 999.999 has an EXACT representation in floating point. 999.999002 maybe the closest value at your chosen precision. Extended type has more precision, but still probably won't be exact. Regards, Peter B ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freepascal Floating Point Issue
Am 22.08.2017 18:11 schrieb "Peter" : > > Hi James, > > Its unlikely that 999.999 has an EXACT representation in floating point. > > 999.999002 maybe the closest value at your chosen precision. > > Extended type has more precision, but still probably won't be exact. Additionally Extended is not cross platform. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freepascal Floating Point Issue
On 21/08/17 22:15, Ralf Quint wrote: On 8/21/2017 3:02 PM, James Richters wrote:> I am having an issue with a simple floating point application. I am setting a variable to a specific value and immediately after I set it, it is not exactly what I set it to. Here's an example>>Draw_GX_Min:=999.999;> Writeln(Draw_GX_Min:3:30);>> The writeln results in 999.999002 >> Why is it not 999.999000 where did 0.02 come from?>Out of thin air... Well, kind of. Double floating point means 16 digitsof precision, so when you force a 30 digit precision output, anythingpast 16 digits is random garbage, at best... And in any event, that's probably much more precision than the GPU is using to generate the final image :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freepascal Floating Point Issue
On 8/22/2017 1:39 PM, Mark Morgan Lloyd wrote: > On 21/08/17 22:15, Ralf Quint wrote: >> On 8/21/2017 3:02 PM, James Richters wrote:> I am having an issue >> with a simple floating point application. I am setting a variable to >> a specific value and immediately after I set it, it is not exactly >> what I set it to. Here's an example>> Draw_GX_Min:=999.999;> >> Writeln(Draw_GX_Min:3:30);>> The writeln results in >> 999.999002 >> Why is it not >> 999.999000 where did 0.02 come >> from?>Out of thin air... Well, kind of. Double floating point means >> 16 digitsof precision, so when you force a 30 digit precision output, >> anythingpast 16 digits is random garbage, at best... > > And in any event, that's probably much more precision than the GPU is > using to generate the final image :-) > Well, older GPUs (at least NVidia, pretty sure similar restrictions apply to AMD) use(d) only 32bit "single" floats, giving a 7 digit precision, though newer ones can also handle 64bit doubles. But there are quite a few differences in how certain FP operations are handled on those GPUs, which result in even doubles only having 14 (instead of 16) digits of precision at best. So while NVidia keeps mentioning IEEE754, their GPUs are in practice not 100% compliant. As I mentioned before, if someone needs to work a lot with floating point arithmetic, it really helps to get yourself acquainted to the way those works and all the possible pitfalls. Btw, anyone know about a BCD math implementation for Free Pascal, like it used to be implemented in DR CBASIC? (those were the days... ;-) ) Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Check In Interface Type Helpers
I just wanted to point out that revision 37023 Sven added type helper support for interfaces. Good job and thank you Sven! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freepascal Floating Point Issue
Turbo Pascal also had a BCD unit. On Aug 22, 2017 6:56 PM, "Ralf Quint" wrote: > On 8/22/2017 1:39 PM, Mark Morgan Lloyd wrote: > > On 21/08/17 22:15, Ralf Quint wrote: > >> On 8/21/2017 3:02 PM, James Richters wrote:> I am having an issue > >> with a simple floating point application. I am setting a variable to > >> a specific value and immediately after I set it, it is not exactly > >> what I set it to. Here's an example>>Draw_GX_Min:=999.999;> > >> Writeln(Draw_GX_Min:3:30);>> The writeln results in > >> 999.999002 >> Why is it not > >> 999.999000 where did 0.02 come > >> from?>Out of thin air... Well, kind of. Double floating point means > >> 16 digitsof precision, so when you force a 30 digit precision output, > >> anythingpast 16 digits is random garbage, at best... > > > > And in any event, that's probably much more precision than the GPU is > > using to generate the final image :-) > > > Well, older GPUs (at least NVidia, pretty sure similar restrictions > apply to AMD) use(d) only 32bit "single" floats, giving a 7 digit > precision, though newer ones can also handle 64bit doubles. But there > are quite a few differences in how certain FP operations are handled on > those GPUs, which result in even doubles only having 14 (instead of 16) > digits of precision at best. So while NVidia keeps mentioning IEEE754, > their GPUs are in practice not 100% compliant. > > As I mentioned before, if someone needs to work a lot with floating > point arithmetic, it really helps to get yourself acquainted to the way > those works and all the possible pitfalls. > > Btw, anyone know about a BCD math implementation for Free Pascal, like > it used to be implemented in DR CBASIC? (those were the days... ;-) ) > > Ralf > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Check In Interface Type Helpers
Am 23.08.2017 02:04 schrieb "Anthony Walter" : > > I just wanted to point out that revision 37023 Sven added type helper support for interfaces. > > Good job and thank you Sven! You're welcome. I wanted to add them for some time already :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
