Difference between revisions of "Talk:Lucas number"
From Free Pascal wiki
Jump to navigationJump to searchm (typo) |
(rebuttal) |
||
Line 50: | Line 50: | ||
I tried to add the lookuptables here, but the wiki insists that is spam ;-) | I tried to add the lookuptables here, but the wiki insists that is spam ;-) | ||
+ | |||
+ | : A: Yeah, I have a [https://www.freepascal.org/docs-html/prog/progse50.html general preference for the CPU's native integer size]. Unlike [[Delphi]] or [[GNU Pascal|GPC]], [[FPC]]'s <syntaxhighlight lang="pascal" enclose="none">integer</syntaxhighlight>/<syntaxhighlight lang="pascal" enclose="none">cardinal</syntaxhighlight> is [[Writing portable code regarding the processor architecture#32 Bit vs. 64_Bit|always of fixed width]], so I used {{Doc|package=RTL|unit=system|identifier=nativeuint|text=<syntaxhighlight lang="pascal" enclose="none">nativeUInt</syntaxhighlight>}}. [However, according to its documentation it's only either 32 or 64 bits, no more, no less, so I can't put code in there for other case.] I just wanna raise awareness for such issues (although it is potentially confusing [hence your question]). I of course would have written {{Doc|package=RTL|unit=system|identifier=uint64|text=<syntaxhighlight lang="pascal" enclose="none">uInt64</syntaxhighlight>}}, too, specifically {{Doc|package=RTL|unit=system|identifier=qword|text=<syntaxhighlight lang="pascal" enclose="none">qword</syntaxhighlight>}}, since the former isn't [https://www.freepascal.org/docs-html/ref/refsu4.html#x26-260003.1.1 mentioned in the Reference Guide] but the latter is. | ||
+ | : Don't ask me, but [[User:Djzepi|Djzepi]] created both [[Fibonacci number]] and [[Lucas number]]. However, I guess it's the other way around: I regard Fibonacci as a general case, and Lucas being a specialization. He introduced calculation of Lucas numbers based on Fibonacci in the [[Special:Diff/84340|page's initial version]]. | ||
+ | : Regarding your code: I want to keep it simple, the examples in the wiki. This implies: | ||
+ | :* I don't wanna assume one is in <syntaxhighlight lang="pascal" enclose="none">{$mode objFPC}</syntaxhighlight> (extended syntax of <syntaxhighlight lang="pascal" enclose="none">exit</syntaxhighlight> routine) | ||
+ | :* has <syntaxhighlight lang="pascal" enclose="none">{$modeSwitch exceptions on}</syntaxhighlight> (implicitly set by <syntaxhighlight lang="pascal" enclose="none">{$mode objFPC}</syntaxhighlight> or <syntaxhighlight lang="pascal" enclose="none">{$mode Delphi}</syntaxhighlight>), ''and'' wants them | ||
+ | :* has <syntaxhighlight lang="pascal" enclose="none">{$modeSwitch result on}</syntaxhighlight> (implicitly set by <syntaxhighlight lang="pascal" enclose="none">{$mode objFPC}</syntaxhighlight> or <syntaxhighlight lang="pascal" enclose="none">{$mode Delphi}</syntaxhighlight>). | ||
+ | : Therefore I regard my implementation as *the best*. [Surprise!] No. Kidding aside, but seriously, I think it is important to embrace robustness of routines, a general notion I derive from Pascal's strictness. You can discern this in <syntaxhighlight lang="pascal" enclose="none">lucasLeftInverseRange</syntaxhighlight>. In conjunction with <syntaxhighlight lang="pascal" enclose="none">{$rangeChecks on}</syntaxhighlight> an out-of-range error can be easily detected (during development). | ||
+ | : [[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|talk]]) 20:25, 11 November 2018 (CET) |
Revision as of 21:25, 11 November 2018
Q: Why not use UInt64 as return type for the function. It should be the same on all platforms.
Remark: it seems a bit strange to me to derive Lucas(n) from Fib(n), because the Fibonacci sequence is jus a special case of the Lucas numbers (with starting values 1,1). --Bart (talk) 19:15, 10 November 2018 (CET)
Here's an example of what I mean:
{
A more general form of the Lucas series, where the 2 starting values
can be set using parameters
}
function LucasGen(L1, L2, N: UInt64): UInt64;
var
i, LucMin1, LucMin2: UInt64;
begin
if (N = 0) then
Raise ERangeError.Create('Lucas function is undefined for 0.');
if (N = 1) then
Exit(L1)
else if (N = 2) then
Exit(L2)
else
begin
LucMin1 := L2;
LucMin2 := L1;
i := 2;
while (i <> N) do
begin
Inc(i);
Result := LucMin2 + LucMin1;
LucMin2 := LucMin1;
LucMin1 := Result;
end;
end;
end;
function Lucas(N: UInt64): UInt64;
begin
Result := LucasGen(2,1,N);
end;
function Fib(N: UInt64): UInt64;
begin
Result := LucasGen(1,1,N);
end;
--Bart (talk) 19:25, 10 November 2018 (CET)
I tried to add the lookuptables here, but the wiki insists that is spam ;-)
- A: Yeah, I have a general preference for the CPU's native integer size. Unlike Delphi or GPC, FPC's
integer
/cardinal
is always of fixed width, so I usednativeUInt
. [However, according to its documentation it's only either 32 or 64 bits, no more, no less, so I can't put code in there for other case.] I just wanna raise awareness for such issues (although it is potentially confusing [hence your question]). I of course would have writtenuInt64
, too, specificallyqword
, since the former isn't mentioned in the Reference Guide but the latter is. - Don't ask me, but Djzepi created both Fibonacci number and Lucas number. However, I guess it's the other way around: I regard Fibonacci as a general case, and Lucas being a specialization. He introduced calculation of Lucas numbers based on Fibonacci in the page's initial version.
- Regarding your code: I want to keep it simple, the examples in the wiki. This implies:
- I don't wanna assume one is in
{$mode objFPC}
(extended syntax ofexit
routine) - has
{$modeSwitch exceptions on}
(implicitly set by{$mode objFPC}
or{$mode Delphi}
), and wants them - has
{$modeSwitch result on}
(implicitly set by{$mode objFPC}
or{$mode Delphi}
).
- I don't wanna assume one is in
- Therefore I regard my implementation as *the best*. [Surprise!] No. Kidding aside, but seriously, I think it is important to embrace robustness of routines, a general notion I derive from Pascal's strictness. You can discern this in
lucasLeftInverseRange
. In conjunction with{$rangeChecks on}
an out-of-range error can be easily detected (during development). - Kai Burghardt (talk) 20:25, 11 November 2018 (CET)