Clojurians Log v2

I've uploaded a patch which changes the regex to [1-9][0-9]* for both numerator and denominator.

may need to back up a bit

the answer is almost certainly precision, floating point numbers are not exact, bigdecimal and ratios are, but there may be other stuff to unpack in the question

https://ask.clojure.org/index.php/14763/inconsistent-errors-ratio-parsing-either-clojure-clojure the context is octal, hex etc

oh that's an interesting edge case

oh, yeah, that doesn't have anything to do with the actual type right, that is just the reader

probably yes

asking because I'm trying to wrap my head around that for two days and feel I'm going crazy)

I mean for sure the answer is "the r radix syntax is almost never used, and octal and hexadecimal support tend to be used in bit twiddling code which is different code from the code that might use ratios, so no one has ever mashed these together before"

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L73 is the regex the reader uses for ratio "tokens"

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L514-L522

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/EdnReader.java#L32 is more relevant here

this particular ask is only looking at edn/read-string

sure, but the ednreader part of that is just copied from lispreader?

clojure' reader has the same behaviour

user=> 0x74/5
Syntax error reading source at (REPL:41:0).
Invalid number: 0x74/5

https://github.com/edn-format/edn/issues/47 is also relevant

just saying. edn does not actually define ratios at all (or octal or hex or radix nums), so this is all in the gray areas

and the answers here don't necessarily need to be the same between the two

so, to summarize - there was no some chain of thought that lead to that decision, right?

hah https://clojurians.slack.com/archives/C03S1KBA2/p1682420586319549?thread_ts=1682420005.366039&cid=C03S1KBA2

I was trying to rationalise ratio with only decimal ints to a friend and feel dumb right now)

> EDN read is more liberal than the spec. I don't see that as a problem, as the spec is the arbiter, not implementations. The spec is going to start conservatively, but these may be added iff there is demand/need.

(from that link)

I believe the intent is that a ratio is defined as having integer numerator and denominator (not valid: bigint N, float, bigdec M, octal, hex, or radix syntax)

undefined

ok, is there then something behind this definition?

do you mean where is "this definition" defined?

I feel like there may be an ask or something somewhere about doing something like bigint for ratios (I think it uses BigInteger under the hood, but could use longs)

no, I mean "it is defined like that because ..."

https://clojure.org/reference/data_structures#_ratio

@hiredman from my skim of the impl, it seems like it autosizes numerator and denominator to long or bigint as needed as part of reading

oh, nice

@delaguardo rational ratios use integers

from my understanding, the intent of the ratio type is to represent rational ratios

I guess his point is more about this:

user=> (integer? 0777)
true

user=> 0777/1
777

my reading of the admittedly minimal reference material and the intent of the impl is that the syntax for ratios is not a composite of other integer syntaxes, it is an atomic definition that defines the numerator and denominator as a string of digits (that leading 0 is allowed is definitely a bug imo)

that is, the syntax is: digit+/digit+

yeah with - prefix optionally

yes, sorry

oh hmm:

-10/11 ;; works 
-10/-11 ;; throws

seems correct and reinforces what I said above

got it. thanks

I will log a jira for the leading 0

https://clojure.atlassian.net/browse/CLJ-2925

patch welcome