Pages: 1

#1 Re: mORMot 2 » Bug in ToDouble » 2025-01-27 11:53:55

mvg7

Hi! Hope someone notice that... ))

#2 Re: mORMot 2 » varCurrency is a bit confusing » 2025-01-23 21:08:34

mvg7
ab wrote:

If you use mORMot VariantToDouble() function you have the proper support and no problem.

The issue comes from your side, using transient string values.

This solution would be perfect if the VariantToDouble() could also convert string type...

#3 mORMot 2 » Bug in ToDouble » 2025-01-23 20:47:08

mvg7
Replies: 2
 
 ToDouble('95.02906953800000000000', z);

In the GetExtended function,  remdigit := 19; ==> should be 18

#4 Re: mORMot 2 » varCurrency is a bit confusing » 2025-01-19 11:16:42

mvg7
ab wrote:

If you use mORMot VariantToDouble() function you have the proper support and no problem.

Indeed! Many thanks, best support ever!!

#5 Re: mORMot 2 » varCurrency is a bit confusing » 2025-01-18 20:36:08

mvg7
ab wrote:

This is how it works with any variant, when you assign a variant (like the "price" function) to a string.
It is not part of mORMot.

Ok! I just beg you to try do do something with it! Like some new TDocVariantOption "dvoPreferDoubleValue"

Like this...

  else if not dvoPreferDoubleValue and (frac < 0) and  // please no varCurrency!:)))  
          (frac >= -4) then       
  begin
    // currency as ###.0123
    TSynVarData(Value).VType := varCurrency;
    Value.VInt64 := v64 * CURRENCY_FACTOR[frac]; // as round(CurrValue*10000)
  end
  else if AllowVarDouble and
          (frac > -324) then // 5.0 x 10^-324 .. 1.7 x 10^308

#6 Re: mORMot 2 » varCurrency is a bit confusing » 2025-01-18 12:04:09

mvg7
ab wrote:

Note first that the 0.156 is stored as varCurrency into the TDocVariant, not as varDouble, because there is less than 5 decimals.
In that respect, mORMot 1 and mORMot 2 are the same.

Sorry but they are not the same, at least my old SynCommons version of 2020:)
This old version in function GetNumericVariantFromJSON first checked 

if AllowVarDouble then
      typ := TextToVariantNumberType(JSON)

and didnt try to produce varCurrency, the value {"price": 0.156} was varDouble.

Now what is confusing:

  var s1, s2: string;
  s1 := _JsonFastFloat('{"price": 0.156}').price; // result is '0,156'
  s2 := _JsonFastFloat('{"price": 0.15678}').price; // result is '0.15678'

depending on decimals count, result's format is different!

Since ToDouble accepts decimal dot as separator, internal conversion varDouble to string also uses decimal dot, one can expect that decimal separator for value {"price": 0.156} is also dot and not comma.

The idea that confusing me is that I was thinkng that when working with mormot, we can assume that decimal separator is dot and dont rely on system settings.

#7 Re: mORMot 2 » varCurrency is a bit confusing » 2025-01-17 22:58:44

mvg7
ab wrote:

I don't understand what you write, because mORMot does not at all take into account FormatSettings.

I write that I would expect APrice =  0.156 in this code:

ToDouble(_JsonFastFloat('{"price": 0.156}').price, APrice);

However actually APrice is not  0.156 in Mormot 2.

#8 mORMot 2 » varCurrency is a bit confusing » 2025-01-17 21:22:15

mvg7
Replies: 9

Hi!
As I understand, since mormot 2 can convert values to varCurrency, unlike Mormot 1, this code wont work If system's decimail separator set as comma:

  
  var APrice: double;
  ToDouble(_JsonFastFloat('{"price": 0.156}').price, APrice);

Im mormot 1 it was like

  
    if AllowVarDouble then
      typ := TextToVariantNumberType(JSON) else
      typ := TextToVariantNumberTypeNoDouble(JSON);

and with delphi's FormatSettings.DecimalSeparator:='.'; the code above worked

Is there any option to prevent the mormot from generating varCurrency ?

#9 Re: mORMot 2 » Parsing a Json Array » 2025-01-03 21:56:34

mvg7
ab wrote:

The easiest is to NOT use variants, but TDocVariantData directly for x.

Or even easier, use a IDocDict instance.

Second method looks like this? 

var x: Variant;
for x in DocList(_Safe(obj.symbols)^) do ;

First method I didnt understand, could you please give a hint... If I use

symbols := _Safe(obj.symbols);

then to iterate using .Items Enumerator,  I need a PVariant?

#10 mORMot 2 » Parsing a Json Array » 2025-01-03 16:06:00

mvg7
Replies: 2

Hi! There are a lot of such topics in the forum, however Im still a bit confused what is the best (fastest) way to parse an array!

In mORMot 2 I have used such approach:

var
  x:                    Variant;
  symbols:           PDocVariantData;
begin
  DoRequest('https://fapi.binance.com/fapi/v1/exchangeInfo');
  obj := _Json(LastResponseA, JSON_OPTIONS_FASTMEM);
  symbols := DocVariantData(obj.symbols);

  for x in symbols.Values do sym := x.symbol;

However in mORMot 2 I have noticed in comments that length(Values)=Capacity so the code should look like

var
  x:                    PVariant;
  symbols:           PDocVariantData;
begin
  symbols := DocVariantData(obj.symbols);

  for x in symbols.Items do sym := x^.symbol;

In this version we should use pointer to Variant, is it correct?
In other topics its recommened to use the _Safe procedure, however I didnt yet understand the reason... could you please clarify! Thanks !

#11 Re: mORMot 2 » Internal counter in AES GCM » 2024-12-23 18:05:35

mvg7
ab wrote:

To be fair, you seem a bit confused within all the implementation details.
The easiest is to use a high-level method like TAesFast[mGcm].MacEncrypt().

Hi again! Maby thanks for your explanations! Indeed I was confused twice:)
In my task I want to encryot messages beeing sent via UDP.
1) I was thinking that a counter in CTR mode increase for next message - now I understand that in increase for next block in 1 message, and for the next message I create new IV,
2) I was also confused thinking that from 12 bits of IV 4 are used for the counter. Now I see that its 4 bits from 16 used for the counter, and 12 are pure for IV.

so the correct workflow is like this:
1) generate random IV of 12 bits
2) encrypt a message, send these 12 bits IV + encrypted + tag
3) repeat step 1 for the next message

#12 Re: mORMot 2 » Internal counter in AES GCM » 2024-12-22 12:37:01

mvg7
ab wrote:

In fact, since the AES GCM is a AES CTR, the IV is XORed with the counter, so it is easier to always start at 1, and ensure a new random IV is transmitted with the encrypted packet (or guessed from an outside independent source).

Sorry let me please clarify once more, you wrote " to always start at 1" but actually we don't use the counter at all? its always 1 cause each new packet is encrypted after reseting the internal counter to 1?
What is the idea of CTR in this case?

ab wrote:

a new random IV is transmitted with the encrypted packet

Its enough to transmit only 8 bytes of IV correct? (12 bytes - 4 bytes which are always Cardinal(1))

#13 mORMot 2 » Internal counter in AES GCM » 2024-12-22 09:30:58

mvg7
Replies: 5

Hi! I did some test but still hardly undertsand: How do I properly use the TAesGcm on mulpiple packets?

I Encrypt a packet, to get its hash I call AesGcmFinal which resets the internal counter to 1.
So the next encryption starts with the initial IV.
What is the correct using of the TAesGcm to work with increasing counter?

#14 Re: mORMot 1 » Wrong floating point json parsing? » 2021-10-03 09:58:42

mvg7
ab wrote:

You need to enable float process.
Floats may not be consistent when converted back and forth.

Use _JsonFastFloat() as documented.

Thanks, I dont see a _JsonFastFloat anywhere even if searching the mORMot-master.zip sources

#15 mORMot 1 » Wrong floating point json parsing? » 2021-10-03 01:25:02

mvg7
Replies: 5

Hi!
this code

var
  obj:    Variant;
  z:      double;
begin
  obj := _JsonFast('{"x": 8.1E-2}');
  z1 := obj.x;
  Memo1.Lines.Add(Format('x: %f', [z]));
end.

produces output "x: 8.10" instead of 0.081, why?

Pages: 1

Board footer

Powered by FluxBB