Re: [fpc-pascal] Loss of precision when using math.Max()

[Paul Nance]

It's hard to make things fool proof, fool's are too ingenius.


On Jul 2, 2018 6:14 PM, "Wolf"  wrote:

> Not so long ago, Florian was proudly bragging about "Pascal does not allow
> you to shoot yourself in the foot
> "
>
> What about this little program:
>
> program Project1;
>
> var a,b: byte;
> begin
>   a:=1;
>   b:=a*(-1);
>   writeln(b);// result: 255
> end.
>
>
> The result is obviously correct, given how the variables are declared. But
> there are no compiler warnings / errors that the assignment b:=a*(-1) is
> fishy, to put it mildly. And if you are serious about strong typing, it
> ought to be illegal, with a suitable complaint from the compiler.
>
> Who is shooting whom in the foot?
>
> Wolf
>
> On 02/07/2018 20:22, Santiago A. wrote:
>
> El 01/07/2018 a las 10:27, C Western escribió:
>
> On 29/06/18 21:55, Sven Barth via fpc-pascal wrote:
>
> More confusingly, if a single variable is used, the expected Max(Double,
> Double) is called:
>
> function Max(a, b: Double): Double; overload;
> begin
>   WriteLn('Double');
>   if a > b then Result := a else Result := b;
> end;
>
> function Max(a, b: Single): Single; overload;
> begin
>   WriteLn('Single');
>   if a > b then Result := a else Result := b;
> end;
>
> var
>   v1: Double;
>   v2: Single;
> begin
>   v1 := Pi;
>   v2 := 0;
>   WriteLn(v1);
>   WriteLn(Max(v1,0));
>   WriteLn(Max(v1,0.0));
>   WriteLn(Max(v1,v2));
> end.
>
> Prints:
>  3.1415926535897931E+000
> Single
>  3.141592741E+00
> Double
>  3.1415926535897931E+000
> Double
>  3.1415926535897931E+000
>
> If this is not a bug, it would be very helpful if the compiler could print
> a warning whenever a value is implicitly converted from double to single.
>
> Well, pascal is a hard typed language, but not that hard in numeric
> issues. I think it is a little inconsistent that it implicitly converts
> '0.0' to double but '0 to single.
>
> Nevertheless, I think it is a bug. It doesn't choose the right overloaded
> function
>
> But the main is this:
> you have several overload options for max
> 1 extended, extended
> 2 double, double
> 3 single, single
> 4 int64, int64
> 5 integer, integer
>
> When it finds (double, single), why does  it choose (single, single)
> instead of (double, double)?
> The natural behavior should be to widen to the greater parameter, like it
> does in expressions.
>
>
>
> ___
> 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] Proposal for new Free Pascal logo

[Paul Nance]

I couldn't agree more.

I still program in (what everyone now calls console) pascal. While working
on a large project, will even go into virtual machine to use the Borland
Pascal 7 IDE, which works a little better than the FPC IDE.

Of course, having started pascal with Borland's Pascal for CPM almost 40
years ago, one might call me an luddite of a fashion.

I have written a few small windows type apps, but still prefer console.
More of the programming is for function instead of display.

On Sun, Apr 1, 2018, 3:29 AM Alexander Grotewohl  wrote:

> I can't help but feel like they'd still just download regular fpc and use
> it at the console with the help of a minimal syntax highlighting editor.
> Don't get me wrong, that's exactly how I like to use fpc, but I already
> know lazarus is awesome for all the bells and whistles.
>
> The problem with the types of classes that use pascal for teaching is the
> same as the ones that use BASIC: They just want to teach you looping and
> using variables and stuff. The absolute basics. In these instances it
> doesn't matter how cool the language is if you're not an experienced enough
> programmer to use it. Perhaps a decent target would be a database course,
> where Lazarus has a better chance to shine, and the users actually have a
> chance to see what's in the RTL/LCL/etc.
> As an aside, I don't think the pascal community is that small, it's just
> spread out. There are a lot of other implementations people cling to
> (myself included).
>
> Alex
>
> On 3/31/2018 7:57 AM, Mr Bee via fpc-pascal wrote:
>
>
> 2018-03-30 16:19 GMT+07:00 Ingemar Ragnemalm :
>
>>
>> The logo is very good, and well connected to the tradtion set by the
>> animated gif. The alternative would be to use a frame of the animation, or
>> similar sideways cheetah, but scaled up so it can have different
>> resolutions. But the head is more compact, which speaks in its favor.
>>
>
> Thank you.
>
>
>> I am not sure how bit the *need* is but it doesn't hurt to have an
>> official still image logo.
>
>
> If we want the young generation to know Pascal with a new paradigm, a
> modern programming language paradigm, I think this branding effort is quite
> important. There are so many people still think that Pascal today is still
> the old 70's Pascal. I even found many universities, at least in my
> country, that still teach Pascal using Turbo Pascal. When I introduced them
> to new and modern Pascal, the FPC/Lazarus (or Delphi), they were amazed at
> how modern Pascal is!
>
> --
>
> Regards,
>
>
> –Mr Bee
>
>
> ___
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.orghttp://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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Obtain file size?

[Paul Nance]

I've always (since Turbo Pascal and now with Free Pascal) used FILESIZE. It
works like a charm.
Even if you do it in assembly its done the same as its done in pascal.

On Oct 6, 2017 7:14 PM, "James Richters" 
wrote:

I am wondering how to get the file size reported by the OS for a particular
file without opening it.  I tried to search for ‘Free Pascal File Size’
and variations but all I get are things like this:



https://www.freepascal.org/docs-html/rtl/system/filesize.html



which is not what I’m looking for.



I’ve been looking through the sysutils reference here:

https://www.freepascal.org/docs-html/rtl/sysutils/index-5.html



and I see disk size, but not file size…



Could someone please point me in the right direction?



James

___
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] Freepascal Floating Point Issue

[Paul Nance]

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] why the 0.5 in the Unix Epoch (for UnixToDateTime function)

[Paul Nance]

Actually the Julian calendar started at noon, the 0.5 is added to get to
midnight. The Julian calendar was developed for astronomers, who view the
sky when it gets dark and want all observing to be referenced to the same
date. Us normal people start our day at midnight so we have to add the
extra half day.  --  Paul

On Aug 1, 2017 7:14 AM, "Dennis"  wrote:

> I just noticed that the definition of the constants have 0.5 in it.
> Why?
>
>
> from dateh.inc
> const
>JulianEpoch = TDateTime(-2415018.5);
>
>UnixEpoch = JulianEpoch + TDateTime(2440587.5);
>
>
> Dennis
> ___
> 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