Undocumented build-time requirement on *READ-DEFAULT-FLOAT-FORMAT*

[lukego]

Spinning out one specific issue from #177:

kons-9 compilation has an undocumented dependency on the Common Lisp variable *READ-DEFAULT-FLOAT-FORMAT* having its default value SINGLE-FLOAT. If the value is changed to DOUBLE-FLOAT then compilation fails. This issue has bitten at least two real-world users (@awolven and myself.)

This issue could be addressed in at least three different ways:

1. Document this requirement and tell the user to take care of it.
2. Ensure "somehow" that this variable has the required value during kons-9 compilation.
3. Update relevant code to be agnostic to the value of this variable e.g. write 0.5f0 instead of 0.5.

Demonstration:

* (setq *read-default-float-format* 'double-float)
* (require :kons-9)
...
; compiling file "/home/luke/git/kons-9/src/kernel/point-origin.lisp" (written 14 NOV 2022 06:52:36 AM):

; file: /home/luke/git/kons-9/src/kernel/point-origin.lisp
; in: DEFUN P-SMOOTH-LERP
;     (ORIGIN.VEC3:LERP KONS-9::P1 KONS-9::P2 (KONS-9::CUBIC KONS-9::F))
; 
; caught WARNING:
;   Derived type of
;   (+ (* -2.0 (* KONS-9::X KONS-9::X KONS-9::X)) (* 3.0 (* KONS-9::X KONS-9::X)))
;   is
;     (VALUES (OR DOUBLE-FLOAT (COMPLEX DOUBLE-FLOAT)) &OPTIONAL),
;   conflicting with its asserted type
;     SINGLE-FLOAT.
;   See also:
;     The SBCL Manual, Node "Handling of Types"

; in: DEFUN P-MIDPOINT
;     (ORIGIN.VEC3:SCALE (ORIGIN.VEC3:+ KONS-9::P1 KONS-9::P2) 0.5d0)
; 
; note: deleting unreachable code
; 
; caught WARNING:
;   Constant 0.5 conflicts with its asserted type SINGLE-FLOAT.
;   See also:
;     The SBCL Manual, Node "Handling of Types"

[kaveh808]

I think this is because our point type is built on vec3 of the origin package (as opposed to dvec3).

It would be good to be able to have the user easily specify if they want single or double floats when they are loading our system. I'd like to avoid having to specify f and d formatting.

What would be some good options for doing this?

[awolven]

It needn't be that complicated. When you need something with a decimal to be a single float you end with "f0" or you clampf or coerce it to single float. When you need something with a decimal to be a double float you end it with d0. Those two cases only happen when the lisp "developer" is optimizing something like point-origin or 3d-vectors. If it doesn't matter whether the number is single float or double float, you can leave off the suffix and use generic math operations and your code should work the same anyway. What we don't want is people writing libraries or core code leaving off the suffix when they are actually trying to say "this is a single float", because then it breaks when read default float format is set to double float. So why am I setting this variable?? Because the people I'm going to deliver the application to expect that the software internally uses double floats when they just specify no suffix. Those "users" as opposed to "developers" might not even know there there is a suffix notation, because they're are not programmers, they are mechanical engineers, and due to the fact that I am giving them a DSL work with, they may only be vaguely aware they are "programming". This has been the case with Icad and Macsyma and dozens of other Lisp engineering programs, not to mention I think Matlab does it too, so they expect other software to be the same, not really caring that it's Lisp.

If you don't want to write a suffix and don't want to mess with the read format, then don't, but it won't be useful to engineers, that's your call.

On Mon, Nov 14, 2022 at 3:29 PM Kaveh Kardan @.***> wrote:

I think this is because our point type is built on vec3 of the origin package (as opposed to dvec3).

It would be good to be able to have the user easily specify if they want single or double floats when they are loading our system. I'd like to avoid having to specify f and d formatting.

What would be some good options for doing this?

— Reply to this email directly, view it on GitHub https://github.com/kaveh808/kons-9/issues/180#issuecomment-1314411909, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABGMMMZ5ZK6JVNZR627UCLWIKVLBANCNFSM6AAAAAAR77VG34 . You are receiving this because you were mentioned.Message ID: @.***>

[awolven]

If you read the original issue in #177, you would also notice that I mentioned that you should be able to specify the type that 3d-vectors and 3d-matrices uses internally. The API functions of those libraries will automatically coerce the number you pass in to be the internal representation specified at build time. When I build 3d-vectors with single floats, the tests on my geometric constraint engine fail because it doesn't have the ability to converge the solution enough to make the program work right. So I am needing 3d-vectors to be configurable by the user, as with read-default-float-format. Kons-9 is using point origin for the case when they expect a component of the vector to be a single float, so I don't think it would trouble anyone to allow :3d-vectors-uses-double-float to be configured at build time.

On Mon, Nov 14, 2022 at 3:49 PM Andrew Wolven @.***> wrote:

It needn't be that complicated. When you need something with a decimal to be a single float you end with "f0" or you clampf or coerce it to single float. When you need something with a decimal to be a double float you end it with d0. Those two cases only happen when the lisp "developer" is optimizing something like point-origin or 3d-vectors. If it doesn't matter whether the number is single float or double float, you can leave off the suffix and use generic math operations and your code should work the same anyway. What we don't want is people writing libraries or core code leaving off the suffix when they are actually trying to say "this is a single float", because then it breaks when read default float format is set to double float. So why am I setting this variable?? Because the people I'm going to deliver the application to expect that the software internally uses double floats when they just specify no suffix. Those "users" as opposed to "developers" might not even know there there is a suffix notation, because they're are not programmers, they are mechanical engineers, and due to the fact that I am giving them a DSL work with, they may only be vaguely aware they are "programming". This has been the case with Icad and Macsyma and dozens of other Lisp engineering programs, not to mention I think Matlab does it too, so they expect other software to be the same, not really caring that it's Lisp.

If you don't want to write a suffix and don't want to mess with the read format, then don't, but it won't be useful to engineers, that's your call.

On Mon, Nov 14, 2022 at 3:29 PM Kaveh Kardan @.***> wrote:

I think this is because our point type is built on vec3 of the origin package (as opposed to dvec3).

It would be good to be able to have the user easily specify if they want single or double floats when they are loading our system. I'd like to avoid having to specify f and d formatting.

What would be some good options for doing this?

— Reply to this email directly, view it on GitHub https://github.com/kaveh808/kons-9/issues/180#issuecomment-1314411909, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABGMMMZ5ZK6JVNZR627UCLWIKVLBANCNFSM6AAAAAAR77VG34 . You are receiving this because you were mentioned.Message ID: @.***>

[kaveh808]

I like the distinction between a (tool) developer and user of the system. It was not something that had occurred to me. I'm fine with a tool or library developer using explicit notations for single and double floats.

We may also need to make the graphics library code aware of this? If memory serves, the OpenGL calls we use expect single floats, which is why I originally had the point class coerce its slots to float. Maybe this will be moot when we transition to Vulkan?

A build-time configuration flag sounds like a good approach. I will admit that I am a bit unclear as to all the code will need to change as a result.

[awolven]

The code will not be complicated to change, the problem is communicating the issue to developers who create dependencies, mostly those who are creating libs for use other than just kons-9. People get stubborn about typing "f0".

In krma, which is the vulkan engine I am developing for kons-9, you can pass any real number to an api function, doubles, ratios, integers, floats, whatever.

On Mon, Nov 14, 2022 at 4:44 PM Kaveh Kardan @.***> wrote:

I like the distinction between a (tool) developer and user of the system. It was not something that had occurred to me. I'm fine with a tool or library developer using explicit notations for single and double floats.

We may also need to make the graphics library code aware of this? If memory serves, the OpenGL calls we use expect single floats, which is why I originally had the point class coerce its slots to float. Maybe this will be moot when we transition to Vulkan?

A build-time configuration flag sounds like a good approach. I will admit that I am a bit unclear as to all the code will need to change as a result.

— Reply to this email directly, view it on GitHub https://github.com/kaveh808/kons-9/issues/180#issuecomment-1314505884, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABGMMNBKNM6BPCGMXYOZWLWIK6DRANCNFSM6AAAAAAR77VG34 . You are receiving this because you were mentioned.Message ID: @.***>

[lukego]

you should be able to specify the type that 3d-vectors and 3d-matrices uses internally

@awolven How would a "failing test" for this look? Can we spin this out into an actionable/testable/fixable issue of its own?

For my part I don't mind which float format kons-9 uses internally provided that there is automatic conversion at the border(s) e.g. between my application and kons-9 and OpenGL.

If dependencies require exact float formats to be chosen at build-time, and there is a conflict between different code wanting different formats in the same image, then that's an interesting problem. My first thought is that it should be possible to compile the library both ways and have them in separate packages like vec/single-float and vec/double-float that can be locally nicknamed to vec in each application. But maybe the place for such discussions is on the upstream repos for those libraries..?

[lukego]

For my part I don't mind which float format kons-9 uses internally

Maybe I speak too soon. In the future I'd like to use Kons-9 for KiCad-like PCB models. I may well want to have a single representation both for visualizing in Kons-9 and for logical operations like design-rule checks. In that case I'd want to build Kons-9 with native double-float support. I'm probably on the same path as @awolven but a few steps behind.

[awolven]

Luke,

What you suggested is probably the way to go. I talked to Nicolas Hafner about doing that with 3d-vectors a couple of years ago. He kind of grumbled about it. I'll have to look at it again to refresh my memory on what the challenge is.

On Tue, Nov 15, 2022 at 1:37 AM Luke Gorrie @.***> wrote:

For my part I don't mind which float format kons-9 uses internally

Maybe I speak too soon. In the future I'd like to use Kons-9 for KiCad-like PCB models. I may well want to have a single representation both for visualizing in Kons-9 and for logical operations like design-rule checks. In that case I'd want to build Kons-9 with native double-float support. I'm probably on the same path as @awolven https://github.com/awolven but a few steps behind.

— Reply to this email directly, view it on GitHub https://github.com/kaveh808/kons-9/issues/180#issuecomment-1314903921, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABGMMNNBRESLXUIWTGD7RLWIM4SBANCNFSM6AAAAAAR77VG34 . You are receiving this because you were mentioned.Message ID: @.***>

[awolven]

Luke,

I have a versions of 3d-vectors and 3d-matrices which define separate packages for single float and double float: :3d-vectors.f, :3d-vectors.d, 3d-matrices.f and :3d-matrices.d in repositories in https://github.com/awolven?tab=repositories. To work with them, you :use one or the other in your defpackage.

-AKW

On Tue, Nov 15, 2022 at 9:46 AM Andrew Wolven @.***> wrote:

Luke,

What you suggested is probably the way to go. I talked to Nicolas Hafner about doing that with 3d-vectors a couple of years ago. He kind of grumbled about it. I'll have to look at it again to refresh my memory on what the challenge is.

On Tue, Nov 15, 2022 at 1:37 AM Luke Gorrie @.***> wrote:

For my part I don't mind which float format kons-9 uses internally

Maybe I speak too soon. In the future I'd like to use Kons-9 for KiCad-like PCB models. I may well want to have a single representation both for visualizing in Kons-9 and for logical operations like design-rule checks. In that case I'd want to build Kons-9 with native double-float support. I'm probably on the same path as @awolven https://github.com/awolven but a few steps behind.

— Reply to this email directly, view it on GitHub https://github.com/kaveh808/kons-9/issues/180#issuecomment-1314903921, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABGMMNNBRESLXUIWTGD7RLWIM4SBANCNFSM6AAAAAAR77VG34 . You are receiving this because you were mentioned.Message ID: @.***>

[brittAnderson]

I wanted to try kons-9 after watching the trailer, but I cannot because of this single float error. Advice on how to fix?

I have used double-float in the past for using some statistical libraries that require it, but as you can see it is set to single-float. I also tried uninstalling and reinstalling cl-opengl and cl-vectors with the single-float setting and the error persists. Thanks.

KONS-9> *read-default-float-format*
SINGLE-FLOAT
KONS-9> (run)
#<SIMPLE-TASKS:CALL-TASK :FUNC #<FUNCTION (LAMBDA () :IN RUN) {1005043BCB}> :STATUS :RUNNING {10050A01A3}>

OpenGL Version: 4.6
Date/time: 2023-08-13-08:53!
An unhandled error condition has been signalled:
   Value of (+ SB-C::X (FLOAT SB-C::Y SB-C::X)) in
   ((SETF AREF) #:NEW1 #:OUT5 0)
   is
     0.0d0,
   not a
     SINGLE-FLOAT.

Backtrace for: #<SB-THREAD:THREAD tid=6789 "main thread" RUNNING {10013C0223}>
0: ("bogus stack frame")
1: (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL T)
2: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {10047BB833}>)
3: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" {10047BB833}> NIL 0)
4: ((LAMBDA (&REST REST) :IN SB-IMPL::GET-EXTERNAL-FORMAT) #<SB-SYS:FD-STREAM for "standard input" {10047BB833}> NIL 0)
5: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {10047BB833}> NIL 0 #<unused argument>)
6: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000021173}> NIL 0 #<unused argument>)
7: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000021173}> NIL (NIL) T)
8: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000021173}> NIL (NIL) NIL)
9: (READ #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000021173}> NIL (NIL) NIL)
10: (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000021173}> #<unused argument>)
11: (SB-IMPL::REPL-FUN NIL)
12: ((LAMBDA NIL :IN SB-IMPL::TOPLEVEL-REPL))
13: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<FUNCTION (LAMBDA NIL :IN SB-IMPL::TOPLEVEL-REPL) {7FC510E7FC1B}>)
14: (SB-IMPL::TOPLEVEL-REPL NIL)
15: (SB-IMPL::TOPLEVEL-INIT)
16: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
17: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
18: (SB-IMPL::%START-LISP)

[kayomarz]

@brittAnderson I don't have an answer, nor am I very experienced but was trying to figure out the cause of the error.

I wonder if this is something specific to you machine.

I also tried uninstalling and reinstalling cl-opengl and cl-vectors with the single-float setting and the error persists.

Would it make sense to try reinstalling / cleaning out quicklisp related libraries?

Did you use quicklisp to quickload kons-9? btw, from the error trace, is it correct that youre using SBCL on linux?

[brittAnderson]

I wonder if this is something specific to you machine.

Perhaps. Using Archlinux. Here is some of the output from glxinfo -B

` Extended renderer info (GLX_MESA_query_renderer):

Vendor: Intel (0x8086)

Device: Mesa Intel(R) Xe Graphics (TGL GT2) (0x9a49)

Version: 23.1.5

Accelerated: yes

Video memory: 15774MB

Unified memory: yes

Preferred profile: core (0x1)

Max core profile version: 4.6

Max compat profile version: 4.6

Max GLES1 profile version: 1.1

Max GLES[23] profile version: 3.2

OpenGL vendor string: Intel

OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2)

OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.1.5

OpenGL core profile shading language version string: 4.60

OpenGL core profile context flags: (none)

OpenGL core profile profile mask: core profile`

Would it make sense to try reinstalling / cleaning out quicklisp related libraries?

Tried. Did not fix the problem. Same error.

Did you use quicklisp to quickload kons-9? btw, from the error trace, is it correct that youre using SBCL on linux?

Yes. I used quickload in the directory that I downloaded kons-9 to.

Yes. I am using SBCL on Linux (Arch distribution)