Return nil/null of data type

[BubikolRamios]

Since line slope at vertical lines is undefined, it will fail at that. Some languages allow null/nil as result.
Unless something like :

Code: Pascal  [Select][+][-]

1. function getLineSlope(P1,P2:Tpoint; out slope:Extended):Boolean;

Any other suggestion ?

Code: Pascal  [Select][+][-]

1. function getLineSlope(P1,P2:Tpoint):Extended;
2. begin
3.  
4.    if P2.Y = 0 and P1.Y = 0 then
5.    begin
6.      result := 0;
7.      exit;
8.    end;
9.  
10.  
11.    result := P2.Y-P1.Y/P2.X-P1.X;
12. end;
13.  

[Thaddy]

This is already implemented.

[Zvoni]

Code: Pascal  [Select][+][-]

1. result := P2.Y-P1.Y/P2.X-P1.X;

I admit, math in school is over 35 years ago, but this looks fishy to me......
(spot the mistake)


and this:

Code: Pascal  [Select][+][-]

1. if P2.Y = 0 and P1.Y = 0 then

checks if the "line" is on the (horizontal) "X-Axis"

You get the "infinity" when a Line is Vertical, as in: the x-coordinate for both points are the same
(or: The "Delta" between both x-coordinates equals 0)

[Warfley]

There is nullable in the RTL, the following uses new functions from trunk which will probably be in 3.2.4

Code: Pascal  [Select][+][-]

1. uses nullable;
2. ...
3. function getLineSlope(P1,P2:Tpoint):specialize TNullable<Extended>;
4. begin
5.  
6.    if P2.Y = 0 and P1.Y = 0 then
7.    begin
8.      result := null;
9.      exit;
10.    end;
11.  
12.  
13.    result := P2.Y-P1.Y/P2.X-P1.X;
14. end;
15.  
16. // Usage
17. if getLineSlope(p1, p2).unpack(slope) then
18.   // Use slope
19. // or
20. slopeOpt := getLineSlope(p1, p2);
21. if not slopeOpt then
22.   // Handle undefined
23. else
24.   // Handle slopeOpt.Value
25. // or
26. slope := getLineSlope(p1, p2).ValueOr(-1); // If undefined return -1
27.  

[Zvoni]

There is nullable in the RTL, the following uses new functions from trunk which will probably be in 3.2.4

Doesn't change the fact his math is wrong

[Khrys]

For floating-point types you could use  +/-Infinity  or  NaN  (quiet or signaling) depending on your use case:

Code: Pascal  [Select][+][-]

1. uses Math;
2.  
3. function GetLineSlope(const P1, P2: TPoint): Extended;
4. begin
5.   if P1.X = P2.X then Exit(NaN);
6.   Result := (P2.Y - P1.Y) / (P2.X - P1.X);
7. end;

[DragoRosso]

For floating-point types you could use  +/-Infinity  or  NaN  (quiet or signaling) depending on your use case:

Code: Pascal  [Select][+][-]

1. uses Math;
2.  
3. function GetLineSlope(const P1, P2: TPoint): Extended;
4. begin
5.   if P1.X = P2.X then Exit(NaN);
6.   Result := (P2.Y - P1.Y) / (P2.X - P1.X);
7. end;

But the result is already "NAN" if the condition meets (i.e. the denominator is zero), why use the "if" clause ?

[Khrys]

But the result is already "NAN" if the condition meets (i.e. the denominator is zero), why use the "if" clause ?

Because by default, division by 0 raises an exception in FPC  (EZeroDivide: Floating point division by zero).

[Warfley]

For floating-point types you could use  +/-Infinity  or  NaN  (quiet or signaling) depending on your use case:

The problem with NaN is, it does not get picked up by the typechecker. If you use an explicit nullable type, you know that the function can return null, so it also serves as documentation, but most importantly, the typechecker forces you to unpack the nullable, requiring you to handle null values.

If you just see the function declaration:

Code: Pascal  [Select][+][-]

1. function GetLineSlope(const P1, P2: TPoint): Extended;

Do you know the function can return NaN? Do you need to handle that case? Well you can't know without looking into the function or additional documentation. If you see:

Code: Pascal  [Select][+][-]

1. function GetLineSlope(const P1, P2: TPoint): TNullable<Extended>;

You know exactly that the author of the function intends to return null in some cases and the compiler "forces" you to check against it

[Zvoni]

But the result is already "NAN" if the condition meets (i.e. the denominator is zero), why use the "if" clause ?

Because by default, division by 0 raises an exception in FPC  (EZeroDivide: Floating point division by zero).

Untested (Warfley's excellent argument not withstanding)

Code: Pascal  [Select][+][-]

1. uses Math;
2.      
3. function GetLineSlope(const P1, P2: TPoint): Extended;
4. begin
5.   Try
6.     Result := (P2.Y - P1.Y) / (P2.X - P1.X);
7.   Except
8.     On EZeroDivide Do Result:=NaN;
9.   End;      
10. end;

[DragoRosso]

But the result is already "NAN" if the condition meets (i.e. the denominator is zero), why use the "if" clause ?

Because by default, division by 0 raises an exception in FPC  (EZeroDivide: Floating point division by zero).

Yes, sorry my fault ... I forgot that for compatibility with Delphi I insert exception masking in Lazarus.

[VisualLab]

For floating-point types you could use  +/-Infinity  or  NaN  (quiet or signaling) depending on your use case:

The problem with NaN is, it does not get picked up by the typechecker.

Of course, because NaN is not a type. It is a specific floating-point value that informs that something went wrong in the calculation. To protect yourself against problems in the code, there are special magic statements for this purpose - for example: if

If someone in their code does not use instructions checking the values ​​of variables or the results of operations, then they have problems.

If you use an explicit nullable type, you know that the function can return null, so it also serves as documentation, but most importantly, the typechecker forces you to unpack the nullable, requiring you to handle null values.

"Nultable" types are not a solution to the problem, but a way of covering or masking it (like sealing a hole in a pipe with a piece of chewing gum). It's pretending that the problem has been solved. A trendy and nasty solution characteristic of the current times, which came from typeless scripting languages. It reminds me of solutions from PHP, where many functions (usually) return a result in the form of a number (e.g. when searching a string of characters). But sometimes such a function returns False or something even more exotic instead of a number (e.g. -1). It's a mess, a dump.

And because C# or Pascal have types, prostheses were created, in the form of so-called nullable "types". An idiotic solution, pretending to be a solution, but in reality causing confusion. Since the function returns a result of the Double type, there is no reason for it to return an empty pointer. A pointer is not a floating-point number.

And since C# and Pascal have types, prosthetics were created, in the form of so-called nullable "types". An idiotic makeshift solution, pretending to be a solution but actually causing confusion. Since the function returns a Double result, there is no reason for it to return an empty pointer. A pointer is not a floating-point number. A function that can return a result of different types is a recipe for disaster. Where is Pascal's strictness of syntax here?

If you just see the function declaration:

Code: Pascal  [Select][+][-]

1. function GetLineSlope(const P1, P2: TPoint): Extended;

Do you know the function can return NaN? Do you need to handle that case?

Of course, this is expected. Because NaN can be (is) used in various libraries (e.g. in Math). And it can (but does not have to) be returned by some functions operating on real numbers. You just have to check it.

Well you can't know without looking into the function or additional documentation. If you see:

Code: Pascal  [Select][+][-]

1. function GetLineSlope(const P1, P2: TPoint): TNullable<Extended>;

But that doesn't help at all. Because you have to check if the function didn't return an empty pointer instead of a floating point number. This is a much worse solution.

You know exactly that the author of the function intends to return null in some cases and the compiler "forces" you to check against it

And its Author forces me to check if the result is not an empty pointer. So I gained nothing. This code checking for that unfortunate NaN would probably be simpler. But there is probably a more elegant solution: checking the contents of variables before performing arithmetic operations according to basic rules of mathematics (e.g. "remember, damn it, don't divide by 0").


The idea of ​​returning results from functions in the form of two different primitive types (e.g. a floating-point number and a pointer) is one of the most idiotic ideas of the last decades. A function that previously returned results of a primitive type (one type!) can suddenly start returning a result of two primitive types. And when? It depends on what it calculates. Such solutions are a complete mess. It also requires inserting additional instructions that will protect your program from crashing when the function returns an empty pointer. Let's assume that a numerical computation library is created that uses this ugly prosthesis. I can already see complaints about the efficiency of calculations or the need to encapsulate calls to such functions with code that checks for empty pointers. A wonderful solution!

[Warfley]

"Nultable" types are not a solution to the problem, but a way of covering or masking it (like sealing a hole in a pipe with a piece of chewing gum). It's pretending that the problem has been solved. A trendy and nasty solution characteristic of the current times, which came from typeless scripting languages. It reminds me of solutions from PHP, where many functions (usually) return a result in the form of a number (e.g. when searching a string of characters). But sometimes such a function returns False or something even more exotic instead of a number (e.g. -1). It's a mess, a dump.

?

The first version of a nullable type is the maybe monad from ML from 1973, the by far strongest typed language at it's time. Nullable types specifically work because of strong typechecking in algebraic or templated typesystems. If you go out of programming languages into mathematics, it is also prevalent in type theory, where you form a union with a bottom type to include the bottom element. So this concept is over a hundred years old by now, long before there were computers.

[VisualLab]

"Nultable" types are not a solution to the problem, but a way of covering or masking it (like sealing a hole in a pipe with a piece of chewing gum). It's pretending that the problem has been solved. A trendy and nasty solution characteristic of the current times, which came from typeless scripting languages. It reminds me of solutions from PHP, where many functions (usually) return a result in the form of a number (e.g. when searching a string of characters). But sometimes such a function returns False or something even more exotic instead of a number (e.g. -1). It's a mess, a dump.

?

The first version of a nullable type is the maybe monad from ML from 1973, the by far strongest typed language at it's time. Nullable types specifically work because of strong typechecking in algebraic or templated typesystems. If you go out of programming languages into mathematics, it is also prevalent in type theory, where you form a union with a bottom type to include the bottom element. So this concept is over a hundred years old by now, long before there were computers.

I understand you. But you don't understand me. You write about academic experiments and mathematical musings. And I write about a specific solution for practical application here and now. There are a lot of different concepts in mathematics and theoretical computer science. Very well. Different concepts need to be explored. But not all of them work in practice (at least for now). And not all of them are suitable for implementation in a programming language (especially imperative). Otherwise, it will create a monster that cannot be used every day.

Yes, functional languages are "trendy" and they are "great" (on paper, on screen, when you read it on a blog). They have everything, they do everything (and even more). Only that... this fashion came and went. Now it's probably the 4th wave. And they are still mainly academic experiments and narrow applications. Does Pascal have to be such a bag into which "every "new" trendy feature of the season is thrown?

[egsuh]

There is nullable in the RTL, the following uses new functions from trunk which will probably be in 3.2.4

Does this mean that we will be able to define types nullable, like following? 

   var
         ni : specialize TNullable<integer>;