datomic has both double and float types, but clojure literals and math functions only use doubles (floats will be widened to doubles).

It looks to me like the input is a double but the schema type is float

(float -72.72186717063904)
=> -72.72187

so what is being printed in the datom is likely a float

that datom value will probably be widened at some point if you manipulate it at all, and will look like this:

(double (float -72.72186717063904))
=> -72.72187042236328

https://docs.datomic.com/on-prem/schema/schema.html#value-types

I strongly suspect you used :db.type/float but you actually wanted :db.type/double

Yeah, this is what my IDE prints, gonna look if it's true that our tx value was a double, not a float

Yes, our schema

yeah, so the double value in the transaction was narrowed to float to fit into the datom

and what you are printing in the datom is a float (a boxed Float object)

You can confirm with (-> mydatom :v class)

Ok, so the browser client lib gives us a Number, which is a 64 bit floating point, which we converted to float, a 32 bit floating point, due to our schema being float instead of double...

And some areas of our code also convert it to float explicitly. We'll have to remodel, I suppose.

I knew Datomic was doing what it should. phew! 😅 Thanks a lot Francis!

That’s a good point, if this value gets into a browser it’s going to be widened no matter what.

you probably just want doubles all the way through

https://docs.datomic.com/cloud/changes.html#973-9132 @U0E0553EF As of the latest release we run Clojure 1.11

Ok. Weird. I just created this stack yesterday.

how was this issue solved, btw? i usually see this kind of behaviour, if i have some .class files getting into the bundled ion code, which are older, than their corresponding source code. the bundle is a zip file and somehow all the file creation and modification dates can become the same date-time, which is the creation time of the zip file itself. in such case, clojure would prefer to load the *.class file, instead of compiling its corresponding source file. to debug this, u should try to clojure -M:ion-dev "{:op :push :uname whatever :creds-profile <your-aws-profile> :region <your-region>}", then look at unzip -l .datomic-ions/datomic/apps/<:app-name from ion-config.edn>/unrepro/whatever.zip| less` it shouldn't have any *.class files in it

@U086D6TBN The issue is that creating a new stack from the AWS Marketplace page results in a stack using an older template. If memory serves, updating the Marketplace page is a slow process. I haven’t gotten around to updating my system yet, but I’m relatively confident that updating the system will resolve this.

ah, i see. i haven't used the marketplace facilities for a long time. we built some clojure tooling (using the cognitect aws lib) to drive cloudformation create/delete/update operations. this is how our cloudformation "control center" looks like a in a REPL NS:

;; Common stack operations
(comment
  (defn $stack [] ($env cfg/dcs))       ;; Storage
  (defn $stack [] ($env cfg/dcs-xxx))  ;; Compute
  (defn $stack [] ($env cfg/apigw))
  ...

  (-> ($stack) (grep> "aud") #_sort)
  (-> ($stack) create-stack req!)
  (-> ($stack) update-stack req!)
  (-> ($stack) (stack-completed? 10))
  (-> ($stack) describe-stack req! :StackStatus)
  (-> ($stack) stack-outputs req!)
  (-> ($stack) stack-outputs req! (grep> "node"))
  (-> ($stack) stack-resources req! #_(resources-with-status "PROGRESS"))
  (-> ($stack) stack-resources req! (grep> "instance"))

  (-> ($stack) stack-resources req! vals (->> (grep #"endpoint" :LogicalResourceId))
      (set/project [:LogicalResourceId :PhysicalResourceId]) print-table)

  (-> ($stack) (merge DescribeStackEvents) req! stack-events-summary
      (->> (take 20)) print-table)

  ;; (-> ($stack) delete-stack req!)

  )